FINAL  REPORT 

on  the  development  of  the  SHIP  ROC/Watchstation 
subsystem  of  the  Navy  Manpower  Requirements  System 

David  R.  Senbenniok 
Patricia  P.  Bruce 
Edward  W.  Lull 

24  Ju] y 1976 


This  development  work  was  conducted  under  the  Operations  Research  Program  of 
the  Office  of  Naval  Research  und/^  Contract  N00014-76-C-G473 . Funding  sup- 


port and  technical  guidance  were  provided  by  the  Navy  Manpower  and  Material 
Analysis  Center,  Atlantic.  This  document  has  been  approved  for  public  re- 
lea..  e and  sale:  distribution  unlimited.  Reproduction  in  whole  or  in  part 
is  permitted  for  any  purpose  of  the  United  States  Government. 


Approved  f.  r p>  yliu  * bouse; 
Distribution  Unlimited 


MANAGEMENT  SCIENCE  SYSTEMS 


771X1  Lmhurx  Pikv  • fulls  Church.  Virginiu  27041  • I70.ll  S2I-69H0 


a o 


REPORT  DOCUMt.RT  AT  ION  P A • 


j 

KIWI)  IN'.TKUC  1 IONS 
IlK!'0;.-i:  rov.i-l,!  i IN- . 1 okM 

Accession  NO. 

l.yMPllN  T 1 s catalog  NUMuLH 

H t RIOO  COVi.ntD 


If  INAL  REF®!'.  • 

24  Nov  l»7  5 — 24  .In  I51  k>  7f. 


RZnCEM 


CONTRACT  OR  GRANT  NUM  ;lCH(*) 


4-76-0^7  3/ 


* PERFORMING  ORGANiZA^; ON  NAME  AND  ADDRESS 

Management  Science  Systems 
7703  Leesburg  Pike  / 

Fa  1 1 s Church,  Virginia  22043 
11.  Controlling  or fice  n awe  and  address 

Oil  ice  of  Naval  Research  f ) J) 

Department  of  the  Navy 

Arlington,  Virginia  22217  

"77  McTTroTiiNG  AGENCY  NAME  6 ADDRESS'//  ditterent  Iron,  Controlling  Ottlce ) IS 

Navy  Manpower  and  Material  Analysis  Center,  Atlantic 

U.  S.  Naval  Station  

Norfolk,  Virginia  23.”  11 


PROGRAM  »*  u EM  EL'  T.  PR  T.  T A jK 

AREA  6 WORK  UNIT  NUMBERS 

NR047-127 


'/  A J u Is?  19  7 6 


rOJMGER  OF  PAuES 
166 


SECURITY  CLASS,  (ot  thla  report) 

Unclassified 


OECL  AS  Sin  CATION  DOWNGRADING 
SCHEDULE 


16  DISTRIBUTION  STATEMENT  (ot  this  Report) 


ADDroved  for  public  release;  distribution  unlimited. 


17.  DISTRIBUTION  STATEMENT  (ot  the  abstract  entered  In  3tock  20,  It  dlflerent  from  Report) 


1y.  KEY  WORDS  (Continue  on  reverse  aide  It  necessary  and  Identity  by  block  number) 

Manpower  Watchstation 

Navy  Manpower  Planning  System  (NAMPS)  Watchstander 

Navy  Manpower  Requirements  System  (NMRS)  \ 

Required  Operational  Capabilities  (ROC)  \ 


20.  ADSTRACT  (Continue  on  reverse  side  It  necessery  and  Identify  by  block  n i*m  S k 1 ng  levels  foT  SilipS  -H'C 

expressed  as  Required  Operational  Capability  (ROC),  which  are  published  by  the 
Office  of  the  CNO  for  each  class  of  ships.  The  Billet  Derivation  (BIDDER)  pro- 
cess of  NMRS  requires  detailed  watchstation  and  watchstander  information  as  an 
operational  workload  input  to  process  with  maintenance  workload  requirements  and 
other  factors  to  determine  billets.  Thus,  the  need  to  relate  the  ROC  for  ships 
with  manpower  as  well  as  provide  BIRDER  with  the  necessary  operational  workload 
information  were  merged  into  the  requirements  for  a subsystem  of  NMRS  called  the 
SHIP/ROC  Watchstation  Module. v.  The  system  was  developed,  tested,  documented,  and 
delivered  to  the  user,  NAVMMAGhANT,  for  use  as  a subsystem  of  NMRS. 


1 f.ov  r.S  If,  ; ivr.r.rt 
■ I «-  hf.Ol  1 


UNCLASSIFIED 

si. cum  1 y classiiic  a , ich  or  this  •>  -a  1 . u. 


TABLE  OF  CONTENTS 

SECTION  PAGE 

1 INTRODUCTION 1-i 

1.1  Background 1-1 

1.2  NAMPS  Functions 1-1 

1.3  Navy  Manpower  Requirements  System  (NMRS) 1-2 

1.4  The  Problem 1-3 

1.5  The  Environment 1-3 

1.6  Functional  Requirements 1-10 

1.7  The  Approach 1-10 

1.8  Results 1-12 

1.9  Other  Relevant  Documentation 1-12 

2 SYSTEM  SUMMARY 2-1 

2.1  System  Application 2-1 

2.2  System  Operation 2-1 

2.3  System  Configuration 2-6 

2.4  System  Organization 2-6 

2.5  Performance 2-6 

2.6  Data  Base 2-6 

2.7  General  Description  of  Components 2-7 

3 SYSTEM  OPERATION 3-1 

3.1  Input  Requirements 3-1 

3.2  Composition  Rules.  . 3-1 

3.3  Vocabulary 3-2 

3.4  Input  Formats 3-2 

3.5  Sample  Inputs 3-6 

3.6  Output  Requirements 3-24 

3.7  Utilization  of  System  Outputs 3-25 

3.8  System  Query  Capabilities 3-26 

3.9  Query  Preparation 3-26 

3.10  Control  Instructions 3-27 

APPENDIX 

A Module  NMWV01  A-l 

B Module  NMWV02  B-l 

C Module  NMWV03  C-l 

D Module  NMWB01  D-l 

E Module  N MW BO 2 E-l 

F Module  NMWF01  F-l 

G Module  NMWF02  G-l 

H Data  Base H-l 


i 


LIST  OF  FIGURES 


Figure  Page 

1.1  General  Approach  to  BILDER  1-G 

1.2  Ship  Input  Processor 1-7 

1.3  Ship  Billet  Derivation 1-8 

2.1  LOAD  Subsystem  of  SHIP  ROC/WS  System 2-2 

2.2  UPDATE  Subsystem  (1)  of  SHIP  ROC/WS  System  ....  2-3 

2.3  UPDATE  Subsystem  (2)  of  SHIP  ROC/WS  System  ....  2-4 

2.4  Watchstation  Generation  Subsystem  of  SHIP  ROC/WS 

System 2-5 

3.1  Delete  Function  Schematic  (UPDATE  Subsystem  1)  . . 3-11 

3.2  Delete  Function  Schematic  (UPDATE  Subsystem  2)  . . 3-20 

A- 1 Program  Flowchart  NMWV01  A-4 

B-l  Program  Flowchart  NMWV02  B-4 

C— 1 Program  Flowchart  NMWV03  C-7 

D-l  Program  Flowchart  NMWB01  D-ll 

E-l  Program  Flowchart  NMWB02  E-14 

F-l  Program  Flowchart  NMWF01  F-10 

G-l  Program  Flov;chart  NMWF02 G-5 

H-l  Katchstations  Required  by  ROC  Elements  H-6 

H-2  Ship  ROC/Watchstation  Module  Pro-Forma  Data 

Structure H-9 

H-3  Ship  ROC/Watchstation  Module  IDMS  Data  Structure  . H-ll 


EXECUTIVE  SUMMARY 


One*of  the  key  functional  requirements  of  the  Navy  Manpower 
Planning  Syst<..".i  (NAMES)  is  the  capability  to  rapidly  determine 
the  manpower  impact  of  varying  the  levels  of  tasking  on  Navy 
activities.  These  tasking  levels  for  ships  are  expressed  as 
Required  Operational  Capabilities  (ROC),  which  are  published 
by  the  Office  of  the  CNO  for  each  class  of  ships.  This 
developmental  function  falls  into  the  realm  of  the  Navy  Man- 
power Requirements  System  (NMRS)  . The  Biile*-  Derivation 
(B2LDER)  process  of  NMRS  requires  detailed  watchstation  and 
watchstander  information  as  an  operational  workload  input  to 
process  with  maintenance  v.’orkload  requirements  and  other 
factors  to  determine  billets.  Thus,  the  need  to  relate  the 
ROC  for  ships  with  manpower  as  well  as  provide  BILDER  with  the 
necessary  operational  workload  information  were  merged  into 
the  requirements  for  a subsystem  of  NMRS  called  the  SHIP  ROC/ 
Watchstation  Module. 

To  relate  the  ROC  to  manpower,  each  element,  of  the  ROC,  called 
a suboperational  capability  (i.e.  Steam  at  full  power;  Provide 
direct  gunfire  support  for  amphibious  landing;  etc.)  was 
examined  with  regard  to  each  Miner  Functional  Area  (i.e.  Signal 
Bridge;  Sonar  Control;  Damage  Control  Central;  etc.)  to  deter- 
mine which  areas  had  to  be  manned  to  support  the  tasking. 

After  completing  a matrix  of  suboperational  capabilities  versus 
minor  functional  areas,  the  relevant  areas  were  reexamined 
with  watchstation  listings  to  pinpoint  which  individual  watch- 
stations  were  absolutely  necessary  to  support  the  tasking. 

These  minimum  watchstation  requirements  were  then  tied  to 
ratc/rating/Navy  Enlisted  Code  by  standards  previously  developed. 

Using  this  methodology  to  acquire  the  necessary  data  to  proceed, 
the  ROC/WS  Module  was  designed  to  perform  the  following  functions 

a.  Given  the  input  of  a ship  identification,  call  the  ship 
ROC  from  the  data  base,  translate  the  suboperational  capabilities 
into  watchstation  requirements,  and  output  to  BILDER  via  an 
input  processor,  minimum  operational  manpower  requirements. 

b.  Entering  the  Module  with  ship  identification  and  a 
revised  ROC,  output  a revised  set  of  minimum  watch-related 
requirements  without  changing  the  permanent  data  associated  with 
the  particular  ship  or  class. 

The  system  was  developed,  tested,  documented,  and  delivered  to 
the  user,  the  Navy  Manpower  and  Material  Analysis  Center, 

Atlantic  for  use  as  a subsystem  of  NMRS. 


iii 


SECTION  1 
INTRODUCTION 


1 . 1 Background 

For  many  years  it  has  been  recognized  in  the  Navy  that  the  most  ex- 
pensive resource  to  provide  is  also  the  most  difficult  one  to  justi- 
fy at  the  detail  level  - manpower.  Quantifying  the  requirements  for 
the  numerous  o ecu;  ational  specialties  at  vaxious  skill  levels  in  an 
environment  as  dynamic  as  the  Navy  is  a very  challenging  undertaking. 
Responding  to  the  need  to  present  a strong  manpower  case  in  a period 
of  shrinking  budgets,  the  Deputy  Chief  of  Naval  Operations  (Manpower) 
(OP-01)  initiated  the  development  of  the  Navy  Manpower  Planning  Sys- 
tem, DAMPS.  Although  the  system  would  have  to  be  large  and  complex, 
the  philosophy  would  be  relatively  simple.  Operational  and  function- 
al capabilities  would  be  related  to  manpower  such  that  required  ca- 
pabilities input  to  the  system  would  yield  manpower  requirements  as 
output.  Although  there  are  other  significant  features  to  NAMPS,  such 
as  the  Alternatives  Generator  and  the  Personnel  and  Training  Projec- 
tions Models,  the  most  basic  and  important  function  of  NAMPS  is  the 
pricing  out  of  required  capabilities  in  terms  of  manpower. 

1 . 2 NAMPS  Functions 

Within  NAMPS,  the  Manpower  Determination  Model  (MDM)  is  the  dynamic 
element  in  the  determination  of  manpower  requirements  and  resolution 
of  alternatives.  The  operational  requirements  (Required  Operational 
Capabilities  - ROC;  Projected  Operational  Environment  - POE;  Re- 
quired Functional  Capability  - RFC)  are  the  independent  variables 
for  manpower  requirements  determination.  The  MDM  uses  the  opera- 
tional requirement  input  to  retrieve  from  the  Manpower  Reference 
Model  (MRM)  the  manpower  required  to  support  each  element  of  op- 
eration. It  aggregates  the  segments  of  required  manpower  to  produce 
the  overall  (projected)  manpower  requirement.  With  this  being  ac- 
complished in  an  automated  system,  it  permits  the  identification  of 
these  requirements  in  sufficient  qualitative  detail  that  personnel 
and  training  plans  may  be  based  upon  a defensible  manpower  package. 
This  also  results  in  significant  improvement  in  the  quality  of  man- 
power cost  estimates.  The  feedback  loops  provided  in  the  system  are 
also  of  great  importance  to  the  operation.  In  those  cases  where 
constraints  are  encountered  which  signify  that  the  manpower  plan  is 
not  achievable,  timely  action  can  be  taken  to  revise  the  require- 
ments as  necessary  during  the  same  planning  cycle.  The  primary  con- 
straints to  impact  upon  the  manpower  plan  are  normally  funding  and 
end  strength  limitations.  However,  personnel  (accession  planning, 
structure  and  promotion  planning,  loss  planning,  etc.)  and  training 
(rating  group  entry  training,  long  lead  time  training  plans,  highly 
specialized  training  plans,  etc.)  considerations  can  also  provide 
the  need  for  feedback  to  manpower  planning.  In  these  cases,  where 
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sufficient:  personnel  management  actions  cannot  be  taken  to  effect 
a match  between  the  projected  personnel  inventory  and  the  manpower 
plan,  the  system  feeds  back  the  relevant  information  to  the  MUM. 

The  MDM  passes  this  information  to  the  Alternative  Generator,  which 
manipulates  the  operational  requirement  inputs  to  derive  feasible 
sets  of  plans,  considering  the  constraints.  The  new  inputs  arc 
passed  through  the  MDM  to  produce  revised  projected  requirements. 

1.3  Navy  Manpower  Requirements  System  (NMRS) 

The  original  concept  of  the  MRM  was  somewhat  flexible  - it  could 
be  either  a data  base  or  a dynamic  model  (or  a combination  of  both) 
Development  of  NM1-  ; has  combined  the  functions  of  the  MDM  (dynamic) 
and  MRM  (reference),  so  that  the  current  design  does  not  have  NMRS 
as  a part  of  the  reference  model,  but  rather  the  opposite. 

The  NMRS  design  provides  the  following  capabilities: 

• Store  reference  data  for  computing  manpower  requirements 
(e.g.,  maintenance  data,  staffing  tables). 

o Store  operational  requirements  data  (e.g.,  squadron  POE, 
shore  RFC) . 

m Accept  user  execution  commands. 

• Accept  user  variability  data. 

• Compute  manpower  requirements  (on  an  activity  basis) . 

• Store  manpower  requirements  (on  an  activity  basis)  linked 
to  the  user  commands  and  variability. 

© Store  manpower  requirerriei  ts  (on  an  activity  basis)  as  ap- 
proved and  promulgated. 

• Produce  draft  requirements  documents  for  analyst/fleet 
review  (including  working  papers  back-up  documentation) . 

• Produce  final  manpower  requirements  documents  for  promul- 
gation . 

© Answer  user  queries  at  detailed  and  aggregate  levels. 

Those  capabilities  serve  the  Navy  in  two  areas  - documenting  the 
actual  requirements  and  projecting  potential  requirements.  In  docu 
menting  actual  requirements,  the  billet  derivation  capability  of 
NMRS  serves  as  a substitute  for  existing  automated  or  manual  sys- 
tems of  manpower  computation.  The  crucial  capability  of  NMRS  that 
is  lacking  in  other  systems  is  the  availability  of  all  the  data  in 
a single  data  base,  for  purpose  of  aggregation  and  queries.  Addi- 
tionally, as  a substitute  for  the  existing  systems,  the  NMRS  compu- 
tation process  offers  refinements  and  efficiencies,  which  could  be 
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expected  to  reduce  the  cost  (dol 
In  projecting  potent  ini  require!: 
billot  derivation  proce  as  into  <j 
output  data  gives  the  user  a qui 
low  cost.  I'arts  of  NAMPS  will  n 
and  some  parts  of  the  process  ma 
omical  to  ever  automate-.  The  pu 
the  NMRS  in  perspective  for  the 
NMRS  is  not  simply  a data  base  - 
Model.  If  sufficient  emphasis  1 
will  be  thi  heart  of  the  automat 
the  solid  foundation  upon  which 

1.4  The  Problem 


1 ar  and  manpower)  of  operation. 

■ills,  the  integration  of  the 
system  including  the  input  and 
ck  turn-around  at  a relatively 
ot.  be  automated  in  the  near  future  - 
y prove  to  be  infeasible  or  unocon- 
roose  of  this  discussion  is  to  place 
near  term  as  well  as  the  fai  term. 

a part  of  the  Manpower  Reference 
s placed  upon  its  development,  it 
ed  NAMPS  for  some  time  to  come; 

NAMPS  can  be  developed. 


Throughout  these  discussions,  one  theme  continues  to  prevail:  Man- 

power is  a resource  needed  to  buy  capabilities.  Tn  the  case  of 
ships,  this  refers  to  the  ROC,  the  Required  Ope  ational  Capabilities 
which  are  published  by  the  Office  of  the  Chief  of  Naval  Operations 
as  guidance  regarding  the  missions  the  ship  should  be  capable  of 
performing.  Even  as  the  ship  should  not  be  assigned  a surface  gun- 
nery mission  if  it  had  no  guns,  it  also  should  not  be  expected  to 
conduct  surface  gunnery  with  no  Gunners  Mates.  However,  in  the 
existing  documentation  systems  there  is  no  direct  or  indirect  re- 
lationship which  ties  a ship's  ROC  to  manpower  requirements.  As  a 
result,  there  was  no  existing  methodology  which  could  be  applied 
in  the  development  of  the  Navy  Manpower  Requirements  System  (NMRS) 
which  could  establish  the  link  between  required  capabilities  and 
manpower.  Management  Science  Systems  proposed  to  identify  the  re- 
lationships between  the  ROC  and  manpower,  and  develop,  test,  and 
deliver  a subsystem  of  NMRS  which  would  automate  the  function,  and 
be  compatible  with  the  associated  subsystems  and  the  data  base 
which  were  being  developed  at  the  Navy  Manpower  and  Material 
Analysis  Center,  Atlantic  ( NAVMMA CLANT ) . 

1 . 5 The  Environment 

In  developing  the  approach  for  this  subsystem,  which  was  called  the 
Ship  ROC/Watchstation  Module,  several  existing  situations  had  to 
be  considered.  Primarily,  the  decisions  regarding  NMRS  which  had 
already  been  made  were  significant,  as  were  other  decisions  which 
emerged  subsequent  to  the  initial  design  of  this  module. 

1.5.1  General  NMRS  System  Concents 


The  Navy  Manpower  Requirements  System  (NMRS)  is  an  automated  system 
being  developed  by  NAVMMACLANT,  under  sponsorship  of  OP-01,  to  serve 
as  the  requirements  generator  for  the  Navy  Manpower  Planning  System. 
In  this  role,  it  can  be  used  to  produce  billet  requirements  (for  the 
NAMPS  Manpower  Reference  Model  - MRM)  and  also  to  investigate  man- 
power requirements  based  on  hypothetical  inputs,  i.e.,  to  simulate 
manpower  requirements  for  different  levels  of  tasking.  The  billet 
requirements,  which  will  be  stored  in  the  data  base,  will  also  serve 


to  ; induce  i.. .power  requirements  documents  for  review  and  promul- 
gation. The  "customers"  of  the  system  wil  l,  include  OP-01  (the 
manpi  v.  r sponsor),  OP-02,  03,  03  (the  warfare  sponsors),  the  Chief 
of  Naval  Material,  and  the  fleets  (lor  manpower  documents) . An 
alii  • mal  ley  "user"  will  be  the  NAVMMACLANT/PAC  Procedures  and 
Analysis  (P&A)  teams,  who  will  have  the  responsibility  for  review- 
ing and  modifying  the  requirements  documents  "in  house"  before 
they  s<  • out  for  t leet  review*  For  this  P&A  review,  the  sys- 
tem will  p-  . de.-e  the  automated  equivalent  of  "working  papers",  en- 
abl.i.:  the  an  . 1 yst  to  track  the  billot  derivation  process  from  in- 
puts to  outputs. 

The  system  will  include  various  subsystems  to  perform  four  major 
fun.-  ions-  i:  intain  the  data  base-,  derive  billet  requirements 

related  to  user  inputs  for  activities,  produce  manpower  requirements 
do-,  unts  (both  real  and  hypothetical),  and  respond  to  queries  re- 
garding the  data  base.  (It  is  understood  here  that  the  data  base 
wrill  include  both  input  data  to  the  billet  derivation  process  and 
outputs  from  it.) 

1.5.2  NMRS  Ob  j active;; 

From  a user  viewpoint,  the  objectives  of  the  system  are  to  perform 

the  functions  described  in  Section  1.5.1  in  a timely,  cost  effective 

manner  with  a minimum  of  manual  intervention.  From  a systems  view- 
point, satisfying  these  user  objectives  requires  the  following  sys- 
tem functions: 

© Recognize  a set  of  user  commands  of  minimal  size  and  trans- 
late them  into  the  appropriate  system  transactions. 

© Process  changes  to  the  data  base  in  such  a way  as  to  mini- 
mize the  impact  of  user  error  on  the  integrity/validity  of 

the  data  base,  and  also  minimize  the  amount  of  information 

required  from  the  user. 

o Derive  the  minimum  (quantitative  and  qualitative)  manpower 
required  to  support  the  ROC/POE  as  described  by  the  user 
or  stored  in  the  data  base;  perform  this  derivation  effi- 
ciently (so  that  multiple  users  can  exercise  the  system 
without  overtaxing  computer/dollar  resouces)  and  with  a 
minimum  of  user  input  required. 

e Respond  to  user  requests  in  the  various  formats  that  the 
users  will  find  convenient  for  their  particular  applica- 
tions . 

• Store  and  manipulate  the  data  base  in  a manner  that  lends 
itself  to  efficient  processing  of  a variety  of  users'  in- 
formation requirements. 
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1 . 5 . 3 lii  1 let  ~ i I 1 : . n (P.ILD!  : , I1)  occss 

The  heart  of  the  NMRS  processing  is  the  derivation  of  billets  in 
the  system  called  BILD:  R which  is  shown  in  Figure  1-1.  Our  concern 
is  with  th*‘  .‘  dip  central  subsystem  which  consists  of  the  Vari- 
ability Pr<  : it  Processor)  , Bi 1 let  Derivation , but  not 

Document  Generation.  The  functional  flow  in  the  Variability  Pre- 
processor is  shown  in  I jure  1-2,  and  th<  Ship  Billet  Derival  Lon 
flow  is  shown  in  Figure  1-3.  In  general,  the  billets  are  derived 
from,  aggregating  the  required  watchstation  information  with  the  re- 
quired maintenance  manhour  information  to  form  an  overall  workload 
req  • . • • nent  , {signing  the  appropriate  allowances,  and  applying  the 
authorized  v.wk  week  to  the  workload  by  work  center.  It  is  im- 
portant to  note  that  c m.plete  watchstation  information  must  be  pro- 
vided to  BILDER  to  derive  billets.  The  source  of  that  information 
is  the  ROC/Watchs tation  Module. 

1.5.4  Variability 


The  concept  of  variability  in  manpower  involves  an  effort  to  opti- 
mize the  effectiveness  of  the  funded  manpower  when  that  level  is 
significantly  less  than  the  documented  manpower  requirements.  It 
is  designed  to  present  discrete  alternatives  to  manpower  managers 
from  which  the  impact  of  authorizing  manpower  at  a level  below  the 
documented  level  can  be  assessed.  The  scope  of  variability  for  ships 
influenced  the  design  of  the  ROC/Watchstation  Module,  since  the 
first  four  forms  shown  below  deal  with  operational  or  watch-related 
requirements . 

A.  Required  Operational  Capability  (ROC)  Modification.  This 
permits  the  operator  to  select  Suboperational  Capabilities  to  sus- 
pend from  the  ship's  ROC  and  provides  the  manpower  impact  of  that 
suspension.  This  alternative  is  actually  defined  in  Ship  Manpower 
Documents  as  Conditional  Manning. 

B.  Suboperational  Capabilities  Modification.  In  the  Ship's 
ROC,  many  Subop 'rational  Capabilities  (SOC)  are  identified  as  being 
provided  for  on  a partial  basis  rather  than  a full  basis.  The  sys- 
tem must  be  able  to  determine  the  manpower  impact  of  changing 
"Partial"  to  "Full"  for  any  SOC  (when  there  is  manpower  impact). 
Additionally,  where  a SOC  is  listed  "Partial"  and  there  are  other 
logical  "Partial"  conditions  which  should  be  considered,  the  capa- 
bility to  determine  the  manpower  impact  of  these  must  be  included. 

C.  Condition  Modification.  This  is  a modification  or  relax- 
ation of  certain  Condition  III  watch  requirements.  This  applies 
when  it  is  recognized  that  the  anticipated  operational  environment 
of  the  ship  would  not  require  the  same  degree  of  continuous  opera- 
tional readiness  as  wartime  steaming  at  sea  would.  It  provides  man- 
power for  Condition  I and  Condition  IV  watch  requirements,  as  well 
as  a limited  Condition  III  capability  where  many  selected  watch  sta- 
tions would  be  manned  on  a two-scction  basis.  The  endurance  of  the 
ship  in  the  modified  Condition  III  operation  would  be  identified  in 
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the  Projected  operational  Environ:  -nt  (POE) . This  alternative  has 
sor.otii.es  been  referred  to  as  the  "surge"  capability. 

D.  POE  Modification.  This  alternative  applies  to  ships  with 
Flight  Quarters,  Replen  i shment , or  other  similar  requirements  iden- 
tified in  the  POE  (e.g.,  provide  UNREP  services  not  to  exceed  42 
hours  per  week).  The  capability  provided  will  enable  the  operator 
to  vary  the  POE  requirement  and  the  system  will  compute  the  manpower 
impact . 

E.  Corrective  Maintenance  Modification.  This  would  permit 
variations  to  the  Corrective  Maintenance  input  at  the  ship-wide  or 
work  center-wide  level. 


F.  Work  Week  Modification.  This  permits  the  operator  to  ex- 
plore the  manpower  impact  of  varying  the  work  week  length. 

G.  Productivity  Allowance  Modification.  Allows  variation  of 
the  Productivity  Allowance  factor. 

1 . 6 Fun  cti  on  a .1  Requirement  s 

Considering  the  above  factors,  functional  requirements  for  the 
Ship  ROC/Watchstation  Module  emerged  as  follows: 

A.  Given  the  input  of  a ship  identification,  call  the  ship 
ROC  from  the  data  base,  translate  the  Sub-Operational  Capabilities 
into  watchstation  requirements,  and  output  to  the  Document  Input 
Processor  (DIP)  of  NMRS  the  minimum  watch-related  manpower  require- 
ments . 

B.  Provide  an  update  capability  so  that  ships  not  initially 
included  in  the  data  base  can  be  entered  by  the  user. 

C.  Provide  the  capability  for  the  user  to  make  permanent 
changes  to  ship  and  class  data  as  necessary. 

D.  Provide  the  capability  to  enter  the  system  with  a ship 
identification  and  revised  ROC,  and  output  to  DIP  a revised  set 
of  minimum  watch-related  manpower  requirements  without  destroying 
or  changing  the  permanent  data  associated  with  that  ship  and  class. 

1 . 7 The  Approach 

In  order  to  meet  the  functional  requirements  and  operate  in  the 
environment  of  NMRS,  the  following  approach  was  adopted: 

Compare  the  Ship  Manpower  Documents  (SMD)  of  all  available 
ships  of  a class.  Note  all  watchstation  exceptions,  and 
where  the  exceptions  are  only  rate/rating,  determine  if  the 
differences  are  related  to  equipment.  (Where  equipments  arc 
the  same,  the  minimum  manpower  requirements  would  be  the  same. 
In  this  case,  the  watchstations  would  not  be  added  to  the 
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exception  list).  The  watchstation  exceptions . 1 ists  become 
the  bases  for  the  ships  files,  ancl  the  listings  of  common 
watchstations  are  the  bases  for  the  class  files. 


Products : 


(a)  Listing  of  watchstations  common  to  a class 
of  ships. 

(b)  Listing  of  watchstati ons  not  common  to  the 
class,  identified  by  ship. 


Using  the  listings  produced  as  described  above  and  the  manpower 
standards  books,  attach  appropriate  manpower  information  to  the 
watchstations.  Also,  attach  the  o ganizational  code  (from  the 
Dictionary  of  Organizational  Codes),  designator/rating,  pay 
grade,  NOBC/NEC,  and  watch  workweek. 


Product:  (c)  Forms  which  tie  watchstations  to  minimize  man- 

power requirements  and  the  other  data  necessary 
for  BILDER. 


Develop  a table  which  lists  Sub-Operational  Capabilities  (SOCs) 
on  one  axis  and  Minor  Functional  Areas  (i.e.,  pilot  house, 
radio  control,  engine  room,  etc.)  on  the  other.  Fill  in  the 
table  indicating  Minor  Functional  Areas  relationship  to  SOCs 
for  a specific  ship. 

Product:  (d)  Table  of  SOCs  vs.  Minor  Functional  Areas. 


Develop  table  for  recording  watchstations  vs.  SOC.  by  Minor 
Functional  Area.  Complete  the  table  for  given  ship. 

Product:  (e)  SOC  to  Watchstation  relationship  per  ship. 


Using  the  product  (c)  above,  develop  class  file  and  individual 
ship  files  for  the  ship  being  processed. 

Product:  (f)  Class  file  input. 

(g)  Ship  file  input. 

Using  the  exception  watchstation  files,  develop  the  remainder 
of  ship  files  for  the  class  in  question. 


In  this  manner  the  necessary  data  was  provided,  properly  formatted 
to  the  data  base  to  permit  the  system  to  meet  the  functional  require- 
ments. The  system  functions  were  divided  into  three  basic  subsystems 
Load,  Update,  and  Watchstation  Generation.  A summary  of  the  system 
is  provided  in  Section  2 of  this  report  and  a description  of  the  sys- 
tem operation  is  included  as  Section  3.  The  system  is  sub-divided 
into  a total  of  seven  programs  or  modules:  NMWV01,  NMWV02,  NMWV03, 

NMWB01,  NMWB02,  NMWF01,  and  NMWF02.  Descriptions  of  these  modules, 
including  program  logic  and  module  flow  charts,  are  included  as 
Appendices  A through  G,  respectively.  A description  of  the  data  base 
is  included  as  Appendix  H. 
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1.8  F :•  L t :? 

The  ineti;  biology  for  relating  RUCs  to  Watchstations  and  extracting 
the  data  necessary  to  support  the  system  were  approved  by  M A VMM AC - 
LANT.  The  decision  by  the  customer  to  require  the  use  of  the 
Cullin  no  Corporation  Integrated  Database  Management  System  (TDMS) 
after  the  initial  system  design  had  been  completed  resulted  in  a 
significant  delay  (over  one  month)  in  the  delivery  or  an  operating 
system.  The  principal  causes  of  the  delay  were  training  and  re- 
design. However,  the  system  was  operational  and  delivered  ior  ac- 
ceptance testing  within  the  scope  of  the  contract. 

1.9  Oth  or  Re  leva::  t Documc  n t at  ion 

The  following  additional  documentation  was  developed  under  this 
contract  and  delivered  to  the  user  of  the  system,  NAVMMACLANT: 

ROC/Watchstation  Module  Users  Manual  28  May  197G 

ROC/Watchstation  Module  Specification  NMWV01  30  June  1976 

ROC/Watchstation  Module  Specification  NMWV02  30  June  1976 

ROC/Watchstation  Module  Specification  NMWV03  30  June  1976 

ROC/Watchstation  Module  Specification  NMWB01  30  June  1976 

ROC/Watchstation  Module  Specification  NMWB02  30  Juno  1976 

ROC/Watchstation  Module  Specification  N.MWF01  30  June  1976 

ROC/Watchstation  Module  Specification  NMWF02  30  June  1976 

ROC/Watchstation  Module  Specification  Data  Base  30  June  1976 

ROC/Watchstation  Module  Specification 

Commands  and  JCL  30  June  1976 


SECT  10:;  2 
SYSTEM  SUMMARY 


2 . 1 System  Applicat ion 

The  ROC/Wntchstation  Module  is  a subsystem  of  the  Navy  Manpower 
Roquiremei  t System,  a key  element  of  the  Navy  Manpower  Planning 
Syst  . (NAMPS).  Where  NMRS  will  produce  Ship,  Sqi  idron,  and 
Shore  Manpower  Documents,  the  ship  ROC/Wa tolls tation  Module  pro- 
vides operational  manpv.ror  information  to  the  Document  Input  Pro- 
cessor for  use  in  the  Billot  Derivation  (BIDDER)  process  for 
ships.  Inasmuch  as  the  ships  have  Required  Operational  Capabili- 
ties (ROCs)  assigned,  and  manpower  is  provided  to  make  the  ship 
and  its  equipment  operational,  a natural  relationship  between  the 
ROC  and  manpower  exists.  The  ROC/Watchstation  Module  establishes 
this  relationship  in  an  automated  system  by  tying  Sub-operational 
Capabilities  to  watchstation  requirements.  Since  the  Projected 
Operational  Environment  (POE)  for  ships  often  contains  informal  ion 
which  impacts  upon  manpower  requirements,  it  is  also  factored  into 
the  system  where  relcv  nt.  This  not  only  provides  essential  inputs 
for  document  production,  it  also  enables  NMRS  to  assess  the  man- 
power impact  of  varying  the  operational  requirements  or  the  envi- 
ronment which  is  planned  for  the  ship. 

Additional  capabilities  will  be  developed  for  NAMPS  at  a later 
date  to  enable  the  aggregating  of  manpower  requirements  at  various 
levels  (i.e.,  ship  class,  ship  type,  rating  group,  program  element, 
etc.)  in  order  to  provide  manpower  managers  with  timely  information 
on  the  manpower  impact  of  policy  decisions  and  program  changes. 

2 . 2 System  Operation 

Figure  2.1  -2.4  show  the  process  flow  of  the  subsystems  of  the 
Ship  ROC/Watchstation  Module.  The  LOAD  subsystem  will  be  operated 
by  the  maintainor  of  the  system,  the  Navy  Manpower  and  Material 
Analysis  Center,  Atlantic,  anytime  that  n cw  watchstation  title, 

ROC  title,  class,  ship,  condition  title,  or  level  information  needs 
to  be  entered  into  the  data  base.  The  outputs  would  include  records 
to  the  data  base,  a display  of  those  records,  edit  reports,  and 
error  reports  (where  relevant) . 

The  UPDATE  subsystems,  also  operated  by  NAVMMACLANT,  provide  the 
means  for  updating  the  watchstation  title,  ROC  title,  Condition 
title,  class,  ship,  watchstation,  watchstation  ROC,  level,  and 
ROC  records  when  necessary  on  an  as-occurring  basis.  The  outputs 
are  new  or  changed  records  with  a display  of  those  records,  edit 
reports,  and  error  reports  (where  relevant:)  . 

The  principle  subsystem,  Watchstation  Generation,  is  operated  by 
NAVMMACLANT  when  NMRS  is  to  be  run  for  a ship,  either  to  produce 
a Ship  Manpower  Document  or  to  query  the  system  for  operational 
manpower  information.  The  operator  input  will  include  identifica- 
tion of  the  ship  and  ROC,  and  the  output  will  bo  .a  watchstation  file 
to  be  passed  to  Die  Document  Input  Processor. 
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Syst.cn  Conf .igurati on 
The  system  is  currently  utilizing  the  following  equipment: 

A.  An  I PM  370-160  computer  located  at  NIH  Computer  Center. 

B.  Approximately  one  3330  disk  drive. 

C.  Card  reader. 

D.  Line  printer. 

2 . 4 Hy:-. tern  Omani  ration 


The  Ship  ROC  ‘ tchstati  >n  Module  system  may  be  logically  divided  into 
three  subsystems:  Load,  Update,  and  VJatchstation  Generation.  The 

Load  subsystem  edits  input  transactions  that  are  submitted  for  the 
purpose  of  entering  certain  record  types  on  the  database.  It  uses 
valid  transactions  to  load  the  following  record  types:  WSTITLE, 

ROCTITLE , CONDTITLE,  CLASS,  SHIP,  LEVEL.  The  Update  subsystem  is 
composed  of  two  distinct  run  streams  each  of  which  is  used  to  update 
certain  record  types  on  the  database.  Input 
systc. . are  validated  before  they  are  used  to 


on  the  database. 


The  run  stream  that  has  as 


transactions  to  this  sub 
perform  any  operations 
its  major  program  NL4WB01 
updates  the  following  record  types:  WSTITLE,  ROCTITLE,  CONDTITLE , 

CLASS,  Si'IP.  The  run  stream  that  has  as  its  major  program  NMWB0  2 
update-,  these  record  types:  LEVEL,  ROC,  I >3 , and  V , 3R0>—  . The  Watch- 

station  Generation  Subsystem  creates  a minimum  watchstation  list  for 
a ship  and  tasking  level  specified  by  an  NMRS  LOAD  or  PRODUCE  command 
The  list  is  output  on  a file  for  subsequent  conversion  to  ISAM  and 
input  to  the  Document  Input  Processor  (DIP) . For  diagrams  of  the 
system  flow  for  each  of  the  Subsystems  described,  see  Figure  2.1. 


.2 . 5 Performance 

Inasmuch  as  the  ROC/Watchstation  Module  is  only  a segment  of  the 
NMRS,  performance  capabilities  cannot  be  meaningfully  measured  until 
it  (NMRS)  is  operational  with  real  data  in  the  data  base.  However, 
information  on-  inputs,  outputs,  and  edits  is  presented  in  Section  2.7 
below. 


2. 6 Data  Base 

There  are  nine  record  types  on  the  Ship  ROC/VJatchstation  Module 
Database.  These  record  types  are  updated  by  the  system  and  used  to 
create  a minimum  watchstation  list  for  a ship  and  tasking  level  to 
ultimately  be  used  as  input  to  DIP.  The  records  are  as  follows: 

A.  CI.ASS  - contains  a class  identifier  and  the  UIC  of  the 
prototype  ship  of  the  class. 

B.  SHIP  - contains  UIC,  shiphull  and  shipname. 
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C.  WS  - t tins  i U IC  or  lass  ident  •'  f i or  (UIC  if  the  watch- 

staticn  is  unique  to  thin  ship  within  its  class;  class  code 
if  the-  watchstation  is  cc:  won  to  all  ships  within  the 
class);  v.a  tch  ' * a ’ ion;  a watchsta  tion  manning  field  that 
indie,  ts  eith  •:  Marine,  Lamps,  CO  - Manning,  whether  sub- 
ject to  surge;  up  to  seven  conditions;  the  following 
watch:.-,  under  inf  .ation:  OEC,  Rating,  Associated  rating, 

mil i t ry  pay  cade,  MLC  or  NOBC , number  of  watchstanders , 
hour of  operati  onal  maintenance  performed  on  watch,  or- 
gan is-  lion a 1 component  code,  a searchkey,  and  a Reserve 
code . 

D.  WSROC  - contains  SOCID  (sub-operatioaal  capability  number). 

II.  LEVEL  - contains  .level,  UIC,  level  name,  and  update  date. 

F.  ROC  - contains  SOCID 

G.  ROCTITLE  - contains  SOCID  and  sub-operational  capability 
code  (e.y.,  MOB  1.1). 

F.  WSTITLE  - contains  v/atchstation  number  and  watchstation 

title. 

G.  CONDTITLE  - contains  condition  and  condition  name. 

2 . 7 G-n 1 ral  Dos c : ription _ of  Corapon e n t s 
2.7.1  LOAD  Subsystem 

A.  Inputs 

Input  will  be  made  to  the  LOAD  subsystem  whenever  there 
is  a nc'-d  to  load  any  of  the  following  record  types  onto  the  Data- 
base: WSTITLE,  F.OCTITLE , CLASS , SHIP,  CONDTITLE , and  LEVEL.  The 
only  control  data  on  each  input  is  the  card  type  which  occupies  card 
positions  one  and  two.  The  card  type  associates  the  input  transac- 
tion with  a particular  record  type;  specifically  Al  - WSTITLE,  Bl  - 
ROCTITLE,  Cl  - CLASS  or  SHIP,  D1  - CONDTITLE,  and  FI  - LEVEL.  Addi- 
tionally, on  the  Cl  card  type  there  is  a field  which  identifies  the 
transaction  as  a CLASS  or  SHIP  load  transaction.  The  origin  of  the 
inputs  will  be  determined  by  User  Interface  Requirements  to  be  de- 
fined for  HMRS . 

B . Proce  r.  sing 

The  input  transactions  are  first  processed  in  NMWV01  where 
the  card  types  are  edited  and  individual  output  files  are  produced 
for  the  different  card  types.  Any  transactions  with  invalid  card 
types  aio  displayed  on  a Preliminary  Edit  Report.  Also  provided  are 
totals  of  cards  read,  cards  written  to  output  files,  and  cards  con- 
taining errors.  The  output  files  are  then  sorted  into  an  order  that 
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w i • ‘ c.dlin  ; 'NV.’VO  3 . One  1!  ta  is  input  to 

t.  :■  , c*  '*i  . rd  ty;  • : edit  i-  . ..’cording  to  dat.  ocifical  ions  re- 

late i to  tl«*.  typo  record  t!  it  t • transaction  will  b ■ used  to  load. 

1 i ■ l tion  < ets  tl  e 1 1 t r < stj  . remen  l.s,  it  will  be  used 

t l a record  ont<  the  Data!  . . If  the  transa  tion  contains  in- 

valid data  it  will  appear  °n  an  error  report  follow  d by  error  mes- 
sage(s)  that  identify  the  field(s)  in  error.  The  on t ire  card  is 
edited  (i.e.,  editing  does  not  end  when  the  first  eror  is  detected). 

Tl  tran  :tions  c it  . : i i n 3 erre  s n ist  1 ■ corrected  and  resubmitt< 
in  the  next  run.  An  edit  report,  will  be  printed,  identifying,  by  card 
type,  uhe  nr  n.-r  of  tran:  action:,  read,  those  writt  n (to  the  database), 
and  those  containing  errors. 

C.  Outputs 


The  following  output  may  be  produced:  An  error  report 

identifying  Invalid  data  on  the  input  transactions;  an  edit  report, 
identifying  by  card  typ_  totals  of  cards  read,  cards  used  to  write 
to  the  Database,  and  curds  with  errors;  a display  c:  records  loaded 
onto  trie  Database.  Any  oc  the  record  types  identified  in  the  'Input1 
section  may  be  loaded  onto  the  Database  depending  on  the  types  of 
transactions  entered. 

2.7.2  Update  Subsystem  (1) 

A.  Inputs 


Input  will  be  made  to  Update  Subsystem  (1)  when  any  of 
the  f ol lowing  record  typos  cn  the  Database  require  an  update : 
WSTITLh,  ROCTITLE,  CONDTITLE,  CLASS,  SHIP.  Each  input  record  may 
be  identified  by  information  provided  in  card  columns  one  through 
eight,  which  contain  a Transaction  Identifier  (1),  Sequence  Number 
(2-3)  , Record  Identifier  (4-5)  and  Transaction  Code  (6-8)  . Input 
function  is  found  in  card  column  nine,  and  input  card  type  is 
located  in  card  columns  ten  and  eleven.  The  card  typo  associates 
the  input  transaction  with  a particular  record  type  on  the  Database; 
specifically  Al  - WSTITLE , B1  - ROCTITLE,  Cl  - CLASS,  C2  - SHIP,  and 
Dl  - CONDTITLE.  The  origin  of  these  inputs  will  be  determined  by 
User  Interface  Requirements  to  be  defined  for  NMRS . 


B . Processing 


The  input  transactions  are  first  processed  in  NMWV02  where 
card  type  and  Transcode  are  edited  and  output,  files  are  generated  for 
the  different  card  types.  Any  cards  with  either  an  invalid  card  type 
or  an  invalid  Transcode  will  appear  on  an  edit  report  and  will 
receive  no  further  processing  by  the  system.  A report  will  be 
printed  specifying  totals  for  cards  read,  cards  written  to  output 
files,  and  cards  containing  errors.  Each  output  file  is  then  sorted 
into  an  order  that  will  ensure  efficient  processing  in  NMWB0.1,  the 
update  module.  In  NMWB01,  the  editing  of  each  transaction  is  based 
on  data  specifications  for  the  type  record  the  transaction  will  up- 
date. If  the  transaction  contains  valid  data,  it  is  used  to  perform 
the  operation  specified  by  the  card  function  (add,  change,  or  delete). 
If  the  transaction  contains  invalid  data,  it  will  be  printed  on  an 
error  report  accompanied  by  error  messages  to  identify  the  problem 
fields.  An  edit  report  is  printed  identifying  by  card  type  and 
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roc.  rd  typo  • • folic  * ng  tot  a 3 • : cards  i.euu,  records  added,  record:; 

changed,  rccoidr,  deleted,  and  cards  with  errors. 

C . On!  ; uts 

The  following  printer  outputs  are  produced:  An  error 

report  displaying  cards  with  invalid  data;  an  edit  report  providing 
totals  .indicut  -d  in  the  Processing  section;  a display  of  records 
changed  on  the  Database  or  added  to  the  Database.  Output,  may  also 
include  new  records  on  the  Database  or  changes  to  existing  records 
on  the  Database. 

2.7.3  Upda te  Subsys tem  ( 2 ) 

A.  Inputs 

Input  will  be  made  to  Update  Subsystem  (2)  when  any  of 
the  following  record  types  on  the  Database  require  an  update:  WS, 

WSROC,  LEVEL,  and  ROC.  Each  input  record  may  be  identified  by 
information  provided  in  card  columns  one  through  eight  which  contain 
a Transaction  Idoncifier  (1),  Sequence  Number  (2-3),  Record  Identi- 
fier (4-5)  and  Transaction  Code  (6-8).  Input  function  is  found  in 
card  column  nine,  and  input  card  type  is  in  card  columns  ten  and 
eleven.  The  card  type  associates  the  input  transaction  with  a 
particular  record  type  on  the  Database;  specifically  Gl  and  III  - 
WS,  G5  and  115  - WSROC,  FI  - LEVEL,  and  Jl  - ROC.  The  origin  of  these 
inputs  v/ill  be  determined  by  User  Interface  Requirements  to  be  de- 
fined for  NMRS . 

B . Processing  . 

The  input  transactions  are  first  processed  in  NMWV02  where 
card  type  and  Transcode  are  edited  and  output  files  are  generated  for 
the  different  card  types.  Any  cards  with  either  an  invalid  card  type 
or  an  invalid  Transcode  will  appear  on  an  edit  report  and  will  receive 
no  further  processing  by  the  system.  A report  will  be  printed  speci- 
fying totals  for  cards  read,  card  written  to  output  files,  and  cards 
containing  errors.  Each  output  file  is  then  sorted  into  an  order 
that  will  ensure  efficient  processing  in  NMWB02,  the  update  module. 

In  NMWB02,  each  transaction  is  edited  based  on  data  specifications 
for  the  type  record  the  transaction  will  update.  If  the  transaction 
contains  valid  data,  it  is  used  to  perform  the  operation  specified  by 
the  card  function  (add,  change,  or  delete).  If  the  transaction  con- 
tains invalid  data,  it  will  be  printed  on  an  error  report  followed 
by  error  messages  to  identify  the  problem  fields.  An  edit  report  is 
printed  identifying  by  card  type  and  record  type  the  following  totals: 
cards  read,  records  added,  records  changed,  records  deleted,  and  cards 
with  errors. 


C .  Outputs 


The  following  printer  outputs 
port  displaying  cards  with  invalid  data; 


are  produced: 
an  edit  report 


An  error  re- 
providing 
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totals  indicated  in  the  Processing  section;  a displ.r.  of  records 
modified  on  the  Database  or  added  to  the  Database.  Output  may  also 
include  new  records  on  the  Database  or  changes  to  existing  records 
on  the  Database. 


2.7.4  Watchstation  Generation  Subsystem 

A .  In  pu  t s 


The  purpose  of  the  input  to  the  Watchstation  Generation 
program  (NMWF01)  is  to  control  the  production  of  a watchstation 
file  for  input  to  DIP.  The  input  will  contain  an  NMRS  PRODUCE  or 
LOAD  and  identification  for  the  ship  and  ROC  for  which  a watch- 
station list  is  required.  The  Ship  ROC/Watchstation  Database  is  an 
associated  input  to  this  subsystem,  providing  organisational  data 
for  ships,  ship  classes,  ship  conditions,  ROC  elements,  and  watch- 
stations.  It  also  contains  specific  data  by  ship  and  class  for 
vatchstations  and  ROCs  and  identifies  the  relationships  between 
them.  The  origin  of  the  input  is  to  be  identified  by  User  Interface 
Requirements  to  be  defined  for  NMRS.  Data  Files  associated  with  the 
input  are  the  Input  Transaction  File  which  consists  of  NMRS  trans- 
action cards,  specifically  the  PRODUCE  and/or  LOAD  commands;  and 
the  Ship  ROC/Watchstation  Module  Database. 


B .  Process ! nq 


Each  input  PRODUCE  cr  LOAD  command  will  generate  a file 
or  all  watchstations  required  for  the  ship  under  its  specified  ROC. 
The  cor and  identifies  the  ship  and  the  ROC.  Thw  database  contains 
w.tichs Lations  common  to  all  ships  in  a class  as  well  as  the 
watchstations  specific  to  each  ship.  Each  class  watchstation  is 
first  examined  to  determine  which  ROC  elements  drive  it.  Then 
each  of  _hese  ROC  elements  is  checked  against  the  ship's  ROC.  If 
the  ship's  ROC  specifics  a ROC  element  which  drives  the  watch- 
station, then  the  watchstation  must  be  manned,  and  a watchstation 
record  is  output  to  the  watchstation  file  for  each  watchstander 
identified  on  the  WATCH  record.  The  watchstation  file  is  then 
sorted  by  UIC,  Tasking  LEVEL,  and  the  first  occurrence  of  ORGCODE 
on  the  record, .and  converted  to  Indexed  Sequential  organization  for 
input  to  the  Document  Input  Processor  (DIP)  Subsystem  of  NMRS. 

C.  Outnuts 

— . r — . — . — - 

Output  consists  of  a watchstation  file  which  contains  one 
record  for  each  watchstander  at  each  watchstation  selected  for  the 
specified  ship  and  ROC.  The  file  is  sorted  and  converted  to  Indexed 
Sequential  organization  in  order  to  provide  WATCH  data  input  to  NMRS 
for  the  production  of  Ship  Manpower  Documents.  The  output  contains 
identification  of  the  ship  (UIC)  and  tasking  level  (LEVEL)  for  which 
the  run  was  made,  a watchstation  ID  number  and  the  following  watch- 
standcr  requirements;  Rato/Rating/NEC,  or  Rank/Designator/NOBC , OMW 
time,  and  organizational  component  listed  by  ship  condition.  Once 
the  watchstation  file  is  converted  to  ISAM,  it  is  passed  to  the 
Document  Input  Processor  Subsystem  (DIP)  for  use  by  the  SHIP  process 
of  the  BILDF.R  subsystem  ol  NMRS. 
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SECT ION  3 


SYSTEM  OPERATIOM 


3.1  Input.  Requirements 

3.3.1  Input  to  LOAD  Subsystem 


Input  to  the  LOAD  subsystem  will  be 
function  of  the  ne.  d to  load  certain  record 
specifically  WSTITLE,  ROCTITLE,  CONDTITLE, 
The  input  must  be  entered  on  punched  cards 
a staff  unit  which  is  to  be  defined  by  User 
for  NMRS . 


required  randomly,  as  a 
types  onto  the  Database 
CLASS,  SHIP,  and  LEVEL, 
and  v.’ill  be  generated  by 
Interface  Requirements 


3.1.?  Input  to  Update  Subsystem 


Input  to  the  Update  Subsystem  (1)  will  be  required  randomly, 
as  a function  of  the  need  to  update  tne  following  record  types  on 
the  Database:  WSTITLE , ROCTITLE,  CONDTITLE,  CL2SS,  and  SHIP.  In- 

put to  the  Update  Subsystem  (3)  will  be  required  randomly,  as  a 
function  of  the  need  to  update  the  following  record  types  on  the 
Database:  WS,  WSROC,  LEVEL,  and  ROC.  The  input  must  be  entered  on 

punched  cards  and  will  3;>e  generated  by  a staff  unit  which  is  to  be 
defined  by  User  Interface  Requirements  for  NMRS. 


3.1.3  Input  to  Watchstation  Generation  Subsystem 

Input  to  the  Watchstation  Generation  Subsystem  will  be  re- 
quired randomly,  as  a function  of  the  need  to  produce  a Ship  Man- 
power Document  for  the  first  time,  or  due  to  any  changes  to  the 
ship  ROC  which  might  impact  the  watchstations . The  input  will  be 
on  a punched  card  and  will  be  generated  by  a staff  unit  (Manpower 
Analyst)  which  is  to  be  defined  by  User  Interface  Requirements  for 
NMRS.  An  associated  input  is  the  Ship  ROC/Watchstation  Module 
Database. 


3 . 2 Compos i Hor.  Rules 

All  card  inputs  to  the  system  must  have  NMRS  Header  information 
in  positions  1-8.  This  header  contains  a Transaction  Identifier 
in  position  1,  a sequence  number  in  positions  2-3,  a record  identifier 
in  positions  4-5  and  a transaction  code  in  positions  6-8.  The 
header  information  is  given  below  by  card  type: 

Al  - A0181ROC 
Bl  - AO 18  3 ROC 

Cl  - AO  18 4 ROC  Update  Subsystem  (1) 

C2  - J0185KOC 
Dl  - A0182ROC 
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FI  - MO IS  CROC 
Cl  - R0188ROC 
111  - KOI  8 8 ROC 
G5  - TO 18 CROC 
H5  - TO ] 8 9 ROC 
J1  - M 0 1 S 7 ROC 

A01  Ci-ID 


Watchstation 


Generation 


The  sequencing  of  all  input  to  the  Update  Subsystems  is  controlled 
by  utility  sorts  and  is  sorted  to  optimize  the  efficiency  of  the 
system.  The  user  should  be  aware  that  for  a particular  card  type, 
all  delete  functions  will  be  executed  first,  the  change  functions 
second,  and  the  add  functions  third.  The  only  functional  restric- 
tion hard-coded  in  the  system  is  that  a CLASS  record  may  not  be 
deleted  until  ail  of  its  member  SHIP  records  have  been  de’eted,  and 
these  operations  may  not  occur  during  the  same  run. 


3 . 3 Vocal 'Ulary 

The  Users  Manual  contains  valid  combinations  of  tics  and  classes 
and  identifies  the  prototype  ship  of  each  c lass,  it  also  contains 

a listing  of  ROC  numbers  and  their  associated  sub-operational 
capability  codes. 


3 . 4 Input  Formats 

In  order  to  prepare  valid  input  to  the  system  the  following  speci- 
fications must  be  met.  The  criteria  will  be  given  by  card  type 
and  will  be  keyed  to  card  columns  that  may  be  identified  on  the  in- 
put layout  forms.  If  an  explanation  for  a particular  field  on  a 
card  is  omitted*,  that  field  is  not  edited  ana  any  value  entered  will 
be  accepted  by  the  system.  Record  layout  forms  are  included  in 
Appendix  C. 

3.4.1  Load  Subsysten 

A.  Card  type  Al  (cc.  1-2) 

- Major  Functional  Area  of  the  Watchstation  must  be 
numeric  (cc.  3-5) 

- Minor  Functional  Area  of  the  Watchstation  must  be 
numeric  or  spaces  (cc.  6-8) 

- Sequence  Code  of  the  Watchstation  must  be. numeric 
or  blank.  It  must  be  blank  if  the  Minor  Functional 
Area  is  blank  (cc.  9 - 12) 

- Watchstation  Title  must  be  present  (cc.  13-44) 

B.  Card  type  B1  (cc.  1-2) 

- ROC  number  must  be  numeric  (cc.  3-6) 

- Mission  Area  must  be  alphabetic  (cc.  7-9) 

- Function  Code  must  be  right- justified  numeric 
(cc.  10  - 11) 
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- Required  Functional  Cup  .bility  Code  must  bo 
right- justified  numeric  (cc.  12  - 13) 

C.  Card  type  Cl  (cc.  1-2) 

- U1C  rust  be  present  (cc.  3-7) 

- Class  must  be  numeric  (cc.  8 - 10) 

- Race:  d Identifier  must  be  'CLS ’ if  a CLASS 
record  is  to  be  loaded;  must  be  blank  if  a 
Sllli’  record  is  to  be  loaded  (cc.  11  - 13) 

- Shiphull  must  be  present  (cc.  14  - 23) 

- Ship  name  must  be  present  (cc.  24  - 55) 

D.  Card  type  Dl  (cc.  1 - 2) 

- Condition  niusu  be  present  (cc.  3-4) 

- Condition  title  must  be  present  (cc.  5-34) 

F.  Card  type  Fl  (cc.  1-2) 

- Level  must  be  present  (cc.  3 - 14) 

- UIC  must  be  present  (cc.  15  - 19) 

- Level  name  must  be  present  (cc.  20  - 51) 

3.4.2  Update  Subsystem  (1) 

A.  Card  type  Al  (cc.  10  - 11) 

- Major  Functional  Area  of  the  Watchstation  must  be 
numeric  (cc.  12  - 14) 

- Minor  Functional  Area  of  the  Watchstation  must  be 
numeric  or  spaces  (cc.  15  - 17) 

- Sequence  Code  of  the  Watchstation  must  be  numeric 
or  blank  (cc.  18  - 21)  . It  must  be  blank  if  the 
Minor  Functional  Area  is  blank. 

- Watchstation  Title  must  be  present  (cc.  22  - 53) 

B.  Card  type  Bl  (cc.  10  - 11) 

- ROC  number  must  he  numeric  (cc.  12  - 15) 

- Mission  Area  must  be  alphabetic  (cc.  16  - 18) 

- Function  Code  must  be  right- justified  numeric 

. (cc.  19  - 20) 

- Required  Functional  Capability  Code  must  be 
right- justified  numeric  or  spaces  (cc.  21  - 22) 

C.  Card  typo  Cl  (cc.  10  - 11) 

- Class  must  bo  numeric  (cc.  12  - 14) 

- UIC  must  be  present  (cc.  15  - 19) 


I 


I 

I 

\ 

I 

I 


D.  Card  type  C2  (cc.  10  - 11) 

- U1C  must  be  present  (cc.  12  - 1G) 

- Class  must  be  numeric  (cc.  17  - 19) 

- Shiphull  must  be-  present  (cc.  2 0 - 29) 

- Ship  name  must  be  present  (cc.  30  - Cl) 

E.  Card  type  111  (cc.  10  - 11) 

- Condition  must  be  present  (cc.  12  - 13) 

- Condition  title  must  be  present  (cc.  14  - 43) 

Note  1 : if  card  function  is  ' D ' , only  data  in  th<  : IRS  H<  der  and 

KEY  subdivisions  must  bo  coded.  (See  Input  Layout  Forms.) 

Note  2:  For  all  card  typos,  Transcode  (cc.  6-0)  must  be  'ROC'; 

function  (cc.  9)  must  bo  'A',  'C 1 , or  ’D’. 

3.4.3  Update  Subsystem  (2) 

A.  Card  type  FI  (cc.  10  - 11) 

- UIC  must  be  present  (cc.  12  - 16) 

- Level  must  be  present  (cc.  17  - 28) 

- Level  name  must  be  present  (cc.  29  - 60) 

- Update  date  must  be  numeric  (cc.  61  - 66) 

- Card  function  must  be  'A',  1 C ' , or  'D'  (cc.  9) 

B.  Card  types  G1  and  III  (cc.  10  - 11) 

- UIC  must  be  present  on  type  G1  (cc.  12.  - 16)  . The  UIC 
must  exist  in  the  SHIP  file  on  the  Database. 

- Class  must  be  numeric  and  must  be  followed  by  two 
spaces  on  type  HI.  The  class  must  exist  in  the 
CLASS  file  on  the  Database.  (cc.  12  - 16) 

- Watchstation  number  must  be  numeric  and  it  must 

exist  in  the  WSTITLE  file  on  the  database.  (cc.  17  - 26) 

- WSMANNING  must  be  space,  'C',  'L',  'M',  'X',  or  space 
(cc.  27) 

- Conditions  must  be  in  the  CONDTITLE  file  on  the  data- 
base and  must  be  left- justified  on  the  input  transac- 
tion. (cc.  28  - 41) 

- The  OEC  for  the  watchstandcr  must  be  'O'  or  'E'. 

(cc.'  42) 

- It  is  invalid  for  Rating/Designation  (cc.  43  - 46)  and 
Associated  Rating  (cc.  47  - 49 ( to  both  bo  present. 

- The  designator  for  an  officer  must  be  'OFF',  spaces, 
or  numerics.  (cc.  43  - 46) 

- The  pay  grade  for  an  enlisted  watchstander  must  be  one 

of  the  following:  'AR' , 'SR',  'FR' , 'AA' , 'SA',  'FA', 

'AN',  'SN',  'FN',  ' 3 A ' , '2A',  '1A',  'CA',  'CS',  'CM'. 

(cc.  50  - 51) 

- The  pay  grade  for  an  officer  must  be  in  the  range  'C'  - 
'P'  (cc.  50  - 51) 
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- The  nunber  of  vatchstanders  field  must  bo  in  the 
range  '01'  - '09',  or  spaces,  (cc.  56  - 57) 

- The  C:;'..'  per  week,  field  uu.  t be  numeric  and  has 
an  assumed  decimal  (99v99)  . (cc.  50  - 61) 

- Either  .Search  hey  (cc.  67-7  0)  or  Dry.  Code 
(cc.  62  - 66)  must  be  present. 

- If  Search  key  is  present,  it  must  be  numeric 
(cc.  67  - 70) 

- Card  function  must  be  '/>'  , 'C1,  or  *D'  (cc.  9) 

C.  Card  types  G5  and  H5  (cc.  10  - 11) 

- UIC  must  be  present  on  G5  transaction  and  must  exist 
in  the  SHIP  file  on  the  database.  (cc.  12  - 16) 

- Class  must  be  numeric  on  the  li 5 transaction  and  must 
exist  in  the  CLASS  file  on  the  database.  It  must  be 
followed  by  two  spaces,  (cc.  12  - 16) 

- Watchstation  number  must  be  numeric  and  it  must  exist 
in  the  WSTITLE  file  on  the  database,  (cc.  17  - 26) 

- The  ROCs  must  be  numeric  and  lef t- justif ied  on  the 
input  transaction.  They  must  exist  in  the  ROCTITLE 
file  on  the  database.  Leadiny  zeroes  must  be  coded. 

(cc.  28  - 43,  45  - 60,  62  - 77) 

- Card  function  must  be  'A'  or  'D'.  (cc.  9) 

D.  Card  type  Jl  (cc.  10  - 11) 

- UIC  must  be  present  and  must  exist  on  the  SHIP  file 
on  the  database,  (cc.  12  - 16) 

- Level  must  be  present.  (cc.  17  - 28) 

- Card  function  must  be  'A'  or  'D'.  (cc.  9) 

- ROCs  must  be  numeric  and  lef t- justif ied  on  the  input 
transaction.  They  must  exist  on  the  ROCTITLE  file 
on  the  database.  Leading  zeroes  must  be  coded. 

(cc.  30  - 45,  47  - 62,  64  - 79)  . 

3.4.4  Watchstation  Generation  Subsystem 

The  input  card  has  a Transaction  ID  in  position  1 which  may 
be  anything.  The  sequence  number  in  positions  2-3  must  be  '01'. 

The  Retord  ID  in  positions  4-5  may  be  anything.  The  Transaction 
code  in  positions  6-8  must  be  'CMD'.  Positions  9-11  will  con- 
tain a command  coda  of  either  ' PRD ' or  'LOD'.  Positions  12  - 16  must 
contain  a UIC  that  exists  on  the  Database.  The  Tasking  Level  field, 
positions  17  - 28  must  contain  a tasking  level  that  exists  for  the 
specified  activity  on  the  Database. 
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A.  Card  type  Al 

The  'Al'  indicates  to  the  system  that  the  card  will  be 
used  to  load  a WSTITLE  record  on  the  .Database . Card  columns  3-12 
contain  the  watchstation  ID  and  card  columns  13  - 44  contain  the 
watchstation  ' s title. 


B.  Card  type  B1 

The  'B1‘  indicates  to  the  system  that  the  card  data  will 
be  used  to  load  a R0CT1TLE  record.  Card  columns  3 - G contain  the 
ROC  number  and  card  columns  7-13  contain  ’the  code  associated  with 
that  nu::'b>er. 

C.  Card  type  Cl  (1) 

The  'Cl1  indicates  that  the  card  data  will  be  used  to 
load  either  a CLASS  record  or  a SHIP  record.  The  'CLS'  in  card 
coJu..  ns  11  - 13  identity  this  card  as  one  to  be  used  to  load  a 
CLASS  record.  The  UIC  in  card  columns  3 - 7 is  that  of  the  proto- 
type ship  of  the  class.  The  class  code  is  in  card  columns  0 - 10; 
the  shiphull  is  j.n  card  columns  14  - 23;  and  the  ship  name  is  in 
card  columns  24  - 55. 

D.  Card  type  Cl  (2) 

The  second  card  type  Cl  is  used  to  load  a SHIP  record. 
The  information  on  the  sample  is  identical  to  that  of  the  first 
example  of  the  Cl  card  with  the  exception  of  card  columns  11  - 13. 
The  fact  that  this  field  is  blank  identifies  this  card  as  one  to 
be  used  to  load  a SHIP  record. 

E.  Card  type  D.l 

The  ' Dl'  indicates  that  this  card  is  to  be  used  to  load 
a CONDTITLE  record.  The  condition  is  located  in  card  columns  3 - 
4 and  the  condition  name  is  in  card  columns  5 - 34. 

F.  Card  type  FI 

The  'FI'  indicates  that  this  card  is  to  be  used  to  load 
a LEVEL  record.  The  level  identifier  is  located  in  card  columns 
3-14.  The  UIC  to  which  the  level  is  to  belong  is  in  card  columns 
15  - 19.  The  name  assigned  to  the  level  appears  in  card  columns 

20  - 51. 
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In  the  above  sample  inputs,  the  following  fields  will  remain  constant 
for  each  card  type:  The  sequence  number  in  card  columns  2-3  will 

always  bo  '01';  the  transaction  code  in  card  columns  6-8  will  always 
be  'ROC'.  The  transcode  identifies  the  major  system  to  which  the  card 
will  bo  input.  The  Trans  ID  (cc.l)  will  be  used  for  sort  purposes  and 
has  no  other  significance.  For  a visual  display  of  the  delete  function 
for  each  card  type,  see  Figure  3.1. 
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A.  Card  type  A1 

Two  fields  on  the  card  identify  il  an  a transaction  to  be 
used  to  update  a WSTITLE  record;  specifically  Record  JD  in  card 

Lui  I - 5 and  c rd  ty;  in  card  columns  20  - 11.  The  first  card 
display,  i will  be  used  to  delete  a WSTITLE  record  as  indicated  by 
the  'D ' in.  card  column  9.  The  only  data  required  for  this  function 
is  t ..  n ID  in  card  columns  12  - 21.  The  second  e:  a pic 
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The  third  type  ' Al' 

card  has  an  'A'  in  card  column  9 and  will  be  used  to  add  a WSTITuE 
recor  the  D I tbase,  The  watchstation  in  must  be  unique  (the 
card  will  be  rejected  if  the  watchstation  ID  coded  already  exists  in 
a WST  .’LL’  record)  and  the  watchstation  title  must  be  present . 

B.  Card  type  B1 

Record  ID  '03'  and  card  type  'Bl'  identify  this  trans- 
action as  cue  u..  i.  : used  tc  update  a RoCTlTLL  record.  The  first 
type  Bl  card  has  a 'D1  in  card  column  9 and  will  be  used  to  delete 
the  ROC1 1TLE  record  with  ROC  number  '0069'.  The  only  data  that  mi  st 
be  coded  for  this  function  is  ROC  number.  The  second  Bl  card  shown 
has  a ' C'  in  card  column  9 and  will  be  used  to  change  a ROCTITLE 
record.  The  ROC  number  (cc . 12  - 15)  is  used  to  identify  the  record 
to  be  changed.  the  ROC  Code  (Mission  Area,  Function  Code,  and  Re- 
quired Functional  Capability  Code,  cc.  16  - 22)  will  replace  what 
currently  exists  in  the  Database  for  the  specified  ROC  number.  The 
third  Bl  card  has  an  'A'  in  card  column  9 and  will  be  used  to  add  a 
ROCTITLE  record  to  the  Database.  The  ROC  number  must  be  unique 
(cannot  already  exist  on  the  Database)  and  the  ROC  code  must  br 
present  for  this  function. 

C.  Card  type  Cl 

Record  ID  '84'  and  card  type  'Cl'  identify  this  transac- 
tion as  one  to.be  used  to  update  a CLASS  record.  The  first  Cl  card 
will  bo  used  to  delete  the  CLASS  record  with  Class  ID  '025'.  The 
class  ID  field  (cc.  12  - 14)  is  the  only  data  field  that  must  be 
coded  for  the  delete  function.  A CLASS  record  may  not  be  deleted 
until  all  of  the  SiilP  records  that  belong  to  that  class  have  been 
deleted.  The  second  Cl  card  displayed  has  a 'C1  in  card  column  9 
and  will  therefore  be  used  to  change  a CLASS  record.  The  class  ID 
(cc.  12  - 14)  is  used  to  identify  the  record  to  be  changed.  The 
U.IC  (cc.  15  - 19)  will  replace  the  one  that  currently  exists  in 
the  Database  for  the  specified  CLASS  record.  The  third  Cl  card 
will  add  a CLASS  record  to  the  Database  due  to  the  'A'  in  card 
column  9.  The  Class  ID  must  be  unique  and  the  UIC  will  be  that  of 
the  prototype  ship  of  the  Class. 
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Card  type  C2 


This  card  type  will  update  a SHU*  record  as  indicated  by 
Record  ID  ' 0 9 ' and  card  type  'C?'.  The  first  type  C2  card  has  a 'D' 
in  card  column  9 and  will  b«j  used  to  delete  the  SHIP  record  _h  UIC 

(cc.  12  - 1G)  '08301'.  The  Class  field  (cc.  17  - 19)  indicat'  r.  the 
cliit.:;  of  which  the  ship  is  a member  and  must  be  present  for  this 
function  as  well  as  the  UIC.  The  second  C2  card  shown  has  a 'C'  in 
card  column  9 and  will  he  used  to  modify  a SHIP  record.  The  UIC 
(cc.  12  - 1G)  will  be  used  to  identify  the  record  to  be  chanced,  and 
the  S -IP  ID  (cc.  17  - 19)  designates  the  Class  to  which  that  ship 
belongs.  The  shiphull  (cc.  20  - 29)  and  ship  name  (cc.  30  -•  61)  will 
replace  what  currently  exists  in  those  fields  on  the  Database  for 
the  SHIP  record  with  UIC  ' 08301 ' . The  third  C2  card  shown  will  add 
a SHIP  record  to  the  Database.  The  ship  will  become  a member  of  the 
Class  specified  in  card  columns  17  - 19  and  will  have  the  shiphull 
and  ship  name  indicated  by  those  fields  on  trie  card. 


E.  Card  type  Dl 

Record  ID  '82'  and  card  type  'Dl'  indicate  that  this 
transaction  will  be  used  to  update  a CONDTITLE  record  on  the  Data- 
base. Tiie  first  bl  card  has  a 'D'  in  card  column  9 and  will  be 
used  to  delete  condition  (cc.  12  - 13)  'C  ' from  the  CONDTITLE  file. 
The  condition  ID  is  the  only  data  that  must  be  coded  for  this 
function.  The  second  example  of  card  type  Dl  will  be  used  to  change 
a CONDTITLE  record  as  indicated  by  the  'C'  in  card  column  9.  The 
condition  (cc,  12  - 13)  is  used  to  identify  the  record  to  be  changed. 
The  condition  title  (cc.  14  - 43)  will  replace  the  title  currently 
in  the  Database  for  condition  '4  '.  The  third  Dl  card  displayed 
will  add  a CONDTITLE  record  to  the  Database.  The  condition  must  be 
unique  and  the  condition  title  must  be  present. 
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Figure  3.1 
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In  the  above  sample  inputs,  the  following  fields  will  remain  constant 
among  card  type:  the  sequence  number  in  card  columns  2-3  will  al- 

ways be  '01';  the  transaction  code  in  card  columns  6-8  will  always 
be  'HOC'.  The  transcode  identifies  the  major  system  to  which  the 
card  will  be  input.  the  Trans  ID  (cc.l)  will  be  used  for  sort  purposes 
and  lias  no  other  significance.  For  a visual  display  of  the  delete 
function  for  each  card  type,  see  Figure  3.2 
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A.  Card  type  II 


This  transaction  is  identified  as  one  to  update  a 
the  '80'  in  the  Record  J D (cc.  4-5)  and  the  ’1'3. 1 
10  - 11)  . The  first  ri  card  displayed  he. s a 
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level  ID  and  UIC  identify  the  record  to  be  modified.  the  level 
name  (cc.  29  - CO)  and  update  date  (cc.  61  - 66)  will  replace  the 
fields  that  currently  exist  in  the  Database  for  level  LI  of  the 
Ship  identified  by  UIC  1 04613'.  The  third  FI  card  displays  a 
transaction  to  be  used  to  add  a LEVEL  record  to  the  Database  ('A1 
in  cc . 9).  Level  'LA'  will  be  added  to  the  Ship  with  UIC  '04644' 


The  level  name  .is 
card  columns  61  - 


in  card  colun 
66  . 


29-60  and  the  upd  te  date  is  in 


B.  Card  types  G1  and  HI 

These  card  types  have  the  same  Record  ID  '88'  because 
both  are  used  to  update  a WS  record.  Card  type  111  updates  WS  records 
that  are  common  to  all  of  the  ships  of  a particular  class 
(cc.  12  - 14).  Card  type  G1  updates  WS  records  that  are  unique  for 
a particular  UIC  (cc.  12  - 16) . The  UTC  and  Class  occupy  the  same 
field  on  the  G1  and  HI  card,  respectively.  The  class  on  the  HI  card 
must  be  followed  by  two  spaces.  Each  function  will  be  described  for 
only  one  of  the  two  card  types.  The  first  G!  example  has  a 'D'  in 
card  column  9 and  will  be  used  to  delete  a WS  record  from  the  Data- 
base. The  UIC  field  (cc.  12  - 16)  and  Watchstation  ID  (cc.  17  - 26) 
care  used  to  identify  the  record  to  be  deleted.  These  are  tne  only 
data  fields  i hat  are  required  for  this  function.  The  second  example 
of  an  HI  card  has  a 'C'  in  card  column  9 and  will  be  used  to  modify 
a WS  record.  The  class  field  (cc.  12  - 14)  and  Watchstation  ID 
(cc.  17  - 26)  are  used  to  identify  the  record  to  be  changed.  The 
data  fields  will  replace  the  fields  that  currently  exist  for  this 
particular  Watchstation  of  the  specified  class.  WSMANNTNG  (cc.  26) 
is  blank  indicating  a surgeable  condition.  The  conditions  under 
which  the  watch  will  be  stood  (cc.  28  - 41)  indicate  that  it  will 
only  be  manned  for  Condition  I.  The  Watchstandcr  requirements  are 
in  card  columns  42  - 72.  The  Watchstander  for  this  Watchstation 
will  be  an  enlisted  man  ('E'  in  cc . 42)  with  a Rating  Designation 
(cc.  43  - 46)  of  'GMG',  therefore  no  Associated  Rating  (cc.  47  - 49) 
is  present.  The  watchstander  will  have  a pay  grade  (cc.  50  - 51)  of 
'EM'  which  will  be  converted  to  a numeric  code  before  it  is  entered 
on  the  Database.  The  watchstander ' s NEC  (cc.  52  - 55)  is  '4296'. 

The  number  of  watchstander s required  (cc.  56  - 57)  is  '02'.  The 
OMW  per  week  (cc.  58  - 61)  that  may  be  done  on  watch  is  13.50  hours. 
Tiie  organisational  code  (cc.  62  - 66)  is  blank  because  the  Search 
Key  (cc.  67  - 70)  is  present.  Reserve  code  (cc.  71  - 72)  is  blank. 
The  third  example  of  a type  G1  card  has  an  'A'  in  card  column  9 and 
will  be  used  to  add  a WS  record  to  the  Database.  The  watchstation 
(cc.  17  - 26)  is  one  that  is  unique  to  the  UIC  '52198'  (cc.  12  - 16). 
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all  of  the  ships  of  a Class  (cc.  12  - x4).  Card  type  C5  update 
WSROC  records  that  are  associated  with  a watchstation  that  is  uni- 
que for  a particular  U1C  (cc.  12  - 16).  The  U10  and  class  ID 
occupy  the  same  field  on  the  G5  and  JI5  card,  respectively. 
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The  UIC  field  (cc.  12  - 16)  and  watchstation  ID  (cc.  17  - 26)  are 
used  to  locate  the  WSROC  record (s)  to  be  deleted.  The  only  WSROC 
that  will  be  deleted  by  this  card  is  '0002  (cc.  28  - 31) . Up  to 
12  cedes  may  he  present  as  in  the  format  shown  on  the  second  ex- 
ample of  the  EI5  cord.  The  change  function  is  invalid  for  both 
the  G5  and  115  card.  The  second  examp' e of  the  i!5  card  will  be  used 
to  add  12  WSROC  records  to  the  Database.  The  class  ID  (cc.  12  - 14) 
and  watchstation  ID  (cc.  17  - 26)  are  used  to  indicate  to  the  sys- 
tem where  the  new  WSROC  records  will  be  placed  and  with  what  records 
the  WSROCs  will  be  associated.  The  WSROC  records  +diat  will  be 
added  will  have  the  folio-ring  values:  000.1,  0U02,  U0D3,  0064  , 0005, 

0006,  0007,  0003  , 0009  , 0010’,  0011,  and  0012.  Please  note  that 
these  values  were  picked  for  use  as  test  data  only. 


D.  Card  type  J1 

This  card  has  a Record  ID  of  '87'.  The  first  example 
shown  will  delete  one  ROC  record  from  the  Database.  The  UIC 
(cc.  12  - 16)  and  Level  ID  (cc.  17  - 28)  are  used  to  identify  the 
ship  and  level  with  which  the  ROC  record (s)  to  be  deleted  ate  associ 
ated.  The  ROC  with  value  '0064'  will  be  deleted  (cc.  .30  - 33).  Up 
to  12  ROC  record.';  may  be  deleted  by  using  one  card.  The  change 
function  is  invalid  for  this  card  type.  The  second  example  has  an 
’A'  in  card  column  9 and  will  add  4 ROC  records  to  the  Database. 

The  records  will  bt  associated  with  the  UIC  (cc.  12  - 16)  and  Level 
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(ec.  17  - 28)  identi.fi  i by  the  c rd.  The  rec<  • added  will 

. . k ^ »v  i l . . rv  -v  **I  I I 1 I 


have  t!  folloviivj  valu 


to  i 2 ROC  reco  ds  may  b<  added  using  one  a rd. 


'00'1.'1,  ’0020'  , ‘0027’,  and  *002^'.  Up 
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The  sample  displayed  has  a Transid  of  'A'  , a sequence  number  of 
' 01 ' , Record  ID  ' L A ' and  Transcode  ' CKD 1 . This  card  will  produce 
a minimum  list  of  watchstatio.ns  required  to  be  manned  under  each 
condition  tor  ship  '04618'  and  tasking  level  'Ll'. 

3 . C Output  Requirements 

3.6.1  Load  and  Update  Subsystems 

The  same  types  of  output  are  generated  by  the  Load,  Update  (1) 
and  Update  (2)  Subsystems.  These  include  error  reports  identifying 
card  input  containing  invalid  data,  edit  total  reports  identifying 
various  functional  totals  by  card  type  and  record  type,  and  displays 
cf  Database  records  that  have  been  added  or  modified.  The  output 
will  be  produced  every  time  one  of  the  subsystems  is  run  due  to  the 
need  to  update  or  load  data  on  the  Database.  Output  from  Update 
Subsystem  (2)  may  contain  classified  information,  but  handling  of  this 
information  has  not  yet  been  defined.  the  output  will  be  distributed 
.o  a Manpower  Analyst  who  will  be  identified  by  User  Interface  Re- 
quirements to  be  defined  for  NMRS . Also  considered  as  associated 
output,  are  updated  records  on  the  Database  and  new  records  on  the 
Database . 

3.6.2  Watchstation  Generation  Subsystem 

Output  from  the  Watchstation  Generation  Subsystem  will  be 
produced  randomly,  as  a function  of  the  need  to  produce  a ship 
manpower  document  for  the  first  time  or  due  to  any  changes  to  the 
ship  ROC  which  might  impact  the  watchstati  ons . The  output,  will  be 
in  the  form  of  a disk  file,  which  will  be  converted  to  ISAM  oi'gani- 
7.ation  to  be  input  to  the  Document  Input  Processor  (Dir)  . 
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3.  / Utile  - v i on  oi’  f.ystem  Outputs 

Js;  general,  there  are  two  major  NMRS  objectives  to  which  the  ROC/ 
Watchstation  Module  responds:  Automated  manpower  document  pro- 

c ion  and  a flexible  manpower  management  information  system.. 

The  utili/.  it  ion  of  outputs  of  the  ROC/Watchstation  Module  are  dis- 
cussed in  tlie  content  of  those  objectives. 

• rinci]  1 syste  output  is  a file  of  minimum  watchstation  re- 
quirement ' (with  skill  categories,  levels,  and  specialties 

sntifi  1)  isoci  il  1 with  i • scified  set  of  operational  re- 
quin  ;nl  called  R iir<  i Op  i tional  Capabilities  (ROC)  which 
have  i ao.i  assigned  to  an  individual  ship.  'Ihis  output,  provided 
to  the  N II  . ■ ument  Input  Pn  . sor  (DIP)  , defines  the  operational 
nr.:  • s./er  workload  in  sufficient  detail  that  it  can  be  processed  in 

t D<  :ix  ition  (BILDER)  with  maintenance-related' workload  to  form 
billets.  billets  arc  the  basic  manpower  units  of  interest  to  the 
users  of  Chip  Manpower  Documents.  In  summary,  the  aggregate  of 
minimum  watchstation  requirem  nts  output  fre.a  the  ROC/Watchstation 
Module  form  an  essential  input  to  the  BILDER  process  - operational 
workload  requirements . 

Looking  at  NMRS  as  a flexible  manpower  management  information  sys- 
tem, other  outputs  from  the  ROC/hatchstat ion  Module  are  needed. 

In  this  context,  NMRS  must  provide  information  to  manpower  managers 
which  assesses  the  manpower  impact  of  changing  the  input  criteria 
from  the  standards  used  for  document  production  to  some  other  set 
of  conditions.  For  example,  .if  a Ship  Manpower  Document  defines 
the  manpower  requirements  for  a ship  to  meet  all  maintenance 
standards  while  existing  at  sea  at  war,  a manpower  manager  may 
wish  to  examine  the  outcomes  of  varying  that  environment.  The 
RCC/W-itchstation  Module  must  be  able  to  respond  to  caanges  to  in- 
put c iteria  where  watchstation  requirem sts  are  involved.  The 
following  are  examples  of  this  type  of  variability: 

1.  Reduce  the  provision  for  flight  quarters  from  1G  hours 
to  12  hours  per  day. 

2.  Eliminate  specific  Sub-Operational  Capabilities  from  the 
ship's  ROC. 

3.  Increase  a ship's  underway  replenishment  requirements 
from  3G  hours  per  week  to  72. 

4.  Identify  specific  Condition  III  watchstations  to  bo 
manned  (when  necessary)  on  a two-section  basis  with 

a correspondingly  reduced  Condition  III  endurance  (i.e., 
from  GO  days  to  14  days) . 

In  cases  such  as  those  described  above,  the  ROC/Watchstation  module 
will  provide  revised  listings  of  minimum  watchstation  requirements 
for  analysis  purposes,  or  a revised  input  to  DIP  in  order  to 
permit  an  overall  billet  impact  assessment. 
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3.8 


item  Query  Ca;  ab i 1 j t j os 


The  System  Query  Capabilities  for  the  Shi.p/ROC  Wa tchstat:  on  Modulo 
D.h  -base  ex: t in  the  form  of  IDMS/CULP1  Reports.  The  reports 
that  may  be  generate]  using  catalogued  procedure:;  arc  the  follow- 
ing: (1)  Level/ROC  Report,  (2)  Ship/ROC/Watehstation  Report,  (3) 

Conaifion  Titlr  •;  he;  n t , ( ••)  1...”  Titles  Report,  and  ( 5)  Watch- 
station  Titles  Report.  The  Leva : /ROC  report  prints  the  contents 
of  the  Level  and  ROC  files  on  the  Database  indicating  the  relation- 
ships between  the  records  on  the  : iles.  The  Sb ip/J OC/Wa t chc t j t ion 

(1)  The  user  may  print 

of  the  Chip,  WS,  and  WSROC  files.  This  report  is 
a manner  to  clearly  show  t!  : interrelationships  among 
types.  (2)  The  user  may  generate  the  report  for  one 


Report  may  be  printed  in  two  possible  w 
the  contents 
formatted  in 
these  record 


ship  only 
watchstat 


The  report  in  this  form  will 
Lor. 3 and  their  associated  sub-oi 


identify  all  of  one  ship 
■erational 


capabilities . 

_ds  must  be  added 

run  stream  that  would  print  the  report  in  its  generalized 
. The  Users  Manual  she.- 5-  card  formats.  The  Condition  Titles 
Lnts  the  contents  of  the  CONDTITLE  file,  displaying  all 
conditions  and  their  associated  condition  names.  The* ROC  Titles 
Report  prints  the  contents  of  the  ROCTITLE  file,  identifying  sub- 
operational  capabilities  with  th.  ir  four  digit  ROC  numbers.  The 


In  order  to  obtain  the  report  in  this  form,  two  a 
to  the 
format. 

Report  p: 


Watchsta tion 
identifying  ; 


Titles  Report  print 


.cn; 


C-  Ci  t + 


nUnlDci*  O 


contents  of  the  WSTITL 
associcit.^d  titles 


f ile , 


Belov/  are  listed  the  reports  that  are.  being  generated: 


1.  ROC  DICTIONARY 

2.  CONDITION  TITLES 

3.  ROC  TITLES 

4.  WATCH STATION  TITLES 

5 . SHIP/ROC/WATCHSTATION 

REPORT 


3 . y Query  Preparation 

Since  all  of  the  reports  generated  are  run  using  catalogued  pro- 
cedures, the  only  user  request  will  be  that  a certain  report  be 
produced.  The  documentation  package,  Culprit  Reports  of  Ship/ 
ROC/V. itch station  Database  identifies  and  displays  the  catalogued 
procedures  used  to  produce  each  report.  The  user  will  specify 
whicli  form  of  the  Ship/ROC/Watchst ation  report  he  wants  and  will 
provide  the  appropriate  input  cards  when  necessary. 
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j . ' Con tro]  Instructions 


Since  the  Cal I inane  IDM3/CULPRIT  Manual  Release  Number  3 explains 
the  technical  aspect  ••  of  CULPRIT  and  its  procedure  for  generating 
? port  s wh  n used  ag  Inst  an  IDMS  data  base,  there  exists  no  n<  d 
for  further  elaboration  here.  The  IDMS/CULPRIT  routine  functions 
as  an  output  processor  in  that  it  allows  the  user  to  generate  a 
variation  of  reports  and/or  files  without  changing  or  affecting 
the  data  base. 


The  user  manual  gives  examples  of  the  JCL  necessary  to  generate 
reports  using  CULPRIT.  These  examples,  along  with  the  file  des- 
criptions and  scheme  definitions  of  the  SHIP/ROC/WATCIJSTATJON 
MODULE  data  base,  were  used  as  guidelines  for  creating  the  neces- 
sary JCL. 
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MODULE  NMWV01 
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Module  Di  scri  ntion 


Kfiv. 7 f)  1 validates  the  card  typo  for  all  input  transactions  to 
module  UMWVO.:  . The  modulo  aorta;  the  valid  transactor  by  card 
typo  and  out;'  s the  dii  erent  tyj  » to  individual  files.  The 
progr<  was  wt  tten  under  contract  nuinbe  r N-00014-7G-C-0473, 
effective  24  Nov  75. 

Modulo  functions 

5he  following  functions  are  performed  by  MMWV'Ol  : 

A.  Edit  all  input  transactions  for  card  type  'Al',  'in'  'cl' 

'Dl',  or  'FI'.  ‘ ' 

B.  Sort  valid  transactions  by  card  type  and  write  the  different 
card  types  to  individual  output  files. 

C.  Print  an  error  report  of  those  transactions  with  invalid  card 
type . 

D.  Print  totals  of  records  read,  records  written,  and  records  v>  ’ Lh 
errors . 


Inputs 

Input  to  NflWVOJ  consists  of  5 types  of  card  input  transactions 
The  5 types  are  identified  in  card  columns  ore  and  two.  Valid 
types  are  'Al',  ' Bl',  'Cl1,  T)l',  and  'FI'.  Cards  with  invalid 
card  types  will  be  accepted  by  the  program  and  printed  on  an  edit- 
report,  but  will  not  be  output  for  processing  by  the  Load  program. 
The  different  input  types  are  described  in  the  Users  Manual.  The 
Input  rile  and  Transaction  formats  may  be  seen  in  the  Module 
Spec ificat ions . 


Outputs 

Output  from  NHWV01  will  consist  of  up  to  five  temporary  files 
and  two  reports,  A file  will  be  output  for  each  different  type  of 
valid  input  transaction.  Those  files  will  bo  input  to  individual 
utility  sorts  and  will  the  si  be  passed  to  the  Load  program.  There 
will  always  be  a report  identifying  the  number  of  input  card  trans- 
actions read,  the  number  written  to  the  output  files,  and  the 
number  having  invalid  card  types.  An  edit  report  identifying  t.i  ana- 
actions  with  invalid  card  types  will  be  printed  when  they  do  occur. 
The  different  output  files  arc  described  in  the  Users  Manual;  and  out- 
put file  formats  and  printer  layouts  may  be  seen  in  the  Module 
Speci f ica tions . 
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Woi  ’ ' St orage 


Working  Storage  consists  of  report  headers  and  detail  lino 
formats,  a table  used  for  printing  Lhe  cm  rent  date  on  the  edit 
roP  ■'  counters  used  to  accum  e tot  ils,  and  subscri  >ts  used 
i-°  •'  : : • ■ data . The  dii  erent  data  element  ■ Ln  the  Working 

Storage  Section  are  d :ribed  in  the  Remarks  paraoraph  o t • 
Cobol  Source  Listing. 


I 


Progra: . Logic 

The  first  step  in  the  processing  is  to  open  files  and  .ini- 
tialize print  areas. 

When  a card  is  road,  an  accumulator  for  transactions  read 
is  incremented.  The  card  is  edited  for  a valid  card  type.  If 
the  card  type  is  valid,  a routine  is  performed  that  writes  the 
transaction  to  an  output  file  based  on  the  card  type,  then  the  • 
is  a branch  to  read  another  card.  If  the  card  lias  an  invalid 
card  type,  it  is  printed  on  an  edit  report,  an  accumulator  for 
transactions  with  errors  is  incremented  and  there  is  a branch  to 
read  another  card. 

When  processing  of  the  input  file  is  complete,  edit  totals 
are  printed,  files  are  closed,  and  program  processing  As  ended. 


A-  3 


Moclul  ■ Dc'cri:  4 ion 
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l.'.'t.'VO?  validates  Lin  card  typo  and  trni 
trans  ict  i<  >ns  to  i < ..  j c s nmk  ( ; and  NM 
the  valid  transactions  by  card  typo  and 
types  to  .individual  tiles.  'the  program 
number  N-00014-76-C-0473,  eff<  :t  Lve  24  I 


::  code  for  all  input 
B02 . Tho  modul e so rts 
outputs  the  different 
was  written  under  contract 
ov  75. 


Mo d ul e F uncti  c:: s 


Iho  following  functions  are  performed  by  NMV.V02: 


A. 


Edit  all  input  transactions  for  transcode  'ROC 

type  'Al',  'IU',  'Cl',  'C2',  'Dl',  ' r*l  ' , 'Gl', 
'115'  , or  ' Jl'  . 


and  card 

ill',  'G5', 


D.  Print  an  error  report  of  those  transactions  with  invalid 
transcode  and/or  card  type. 

C.  Print  totals  of  records  rend,  records  written,  and  records 
with  errors. 


D.  Sort  valid  transactions  by  card  type  and  write  different  ca?  1 
types  to  individual  output  files. 


Input: 


Input  to  K. v.-rv C) 2 consists  or  10  types  of  card  input  transactions 
identified  in  card  columns  10-11.  The  valid  types  arc  'Al',  ' Bl  ' 
|C1 ' , 'D1 ' , ' FI 1 , ' G1  ’ , '111',  ' G5  1 , 'IIS',  and  'Jl'.  Cards  wi  th 

invalid  card  types  wi1!  be  accepted  by  the  program  and  printed  on 
an  edit  report,  but  will  not  be  output  for  further  processing. 


Ou  tpu  ts 

Output  from  NMWV02  will  consist  of  up  to  four  temporary  files  rid 
two  reports.  Which  files  are  output  will  depend  on  the  validity 
of  the  input  transactions  and  to  which  update  program  they  will 
eventually  be  input.  Basically  one  file  for  each  valid  type  of 
transaction  will  be  written.  There  will  always  be  a report  identi- 
fying the  number  of  input  card  transactions  read,  the  number  written 
to  the  output  files,  and  the  number  having  invalid  card  types.  An 
edit  report  identifying  transactions  with  invalid  card  types  or 
invalid  NMRS  Transcodes  will  be  printed  when  these  errors  occur. 


\ 
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Working  R forage 


Wor).  ing  Stoiacjo  consists  of  report  headers  and  detail  line  formats, 
a table  used  for  printing  the  current  date  on  the  edit  report, 
counters  used  to  accumulate  totals,  and  subscripts  used  to  access 
table  data.  The  different  data  elements  in  the  Working  Storage 
Section  are  described  in  the  Remarks  paragraph  of  the  Cobol  Som  ce 
Listing 


Program  Logic 

The  first  stet  in  the  processing  is  to  open  files  and  ini- 
tialize print  areas. 

When  a card  is  read,  an  accumulator  for  transactions  read 
is  incremented . The  card  is  edited  for  a valid  card  type  and 
NMRS  Transcode.  If  these  two  fields  are  valid,  a routine  is 
performed  that  writes  the  transaction  to  an  o'tput  file  based  on 
the  card  type,  an  accumulator  for  transactions  written  is  incre- 
mented, and  there  is  a branch  to  read  another  card.  If  the  caid 
has  invalid  data,  it  is  printed  on  an  edit  report,  an  accumulator 
for  transactions  with  errors  is  incremented  and  there  is  a branch 
to  read  another  card. 

When  processing  of  the  input  file  is  complete,  edit  totals 
are  printed,  files  are  closed,  and  program  processing  is  ended. 


I 

I 

I 


APPENDIX  C 


MODULE  NMWV03 


^-1 


L 


Character 5 sties 


a.  IT-REC  is  the  card  input  transaction.  The  file  is  a 
concatenation  of  up  to  five  individual  files  that 
are  output  from  utility  sorts. 

b.  Each  input  transaction  is  edited  according  to  specifica- 
tions for  the  particular  record  type  associated  with  the 
transaction.  These  requirements  are  stated  in  '2.2  Module 
Functions'.  If  the  record  contains  valid  data,  the 
transaction  is  used  to  load  a particular  Database  record; 
otherwise  the  transaction  is  printed  on  an  error  report 
where  the  invalid  card  data  is  identified. 

c.  Tne  data  in  positions  1-2  is  the  card  type  which  identifies 
which  Database  record  is  to  be  added.  . The  rest  of  the 
card  data  is  used  to  build  the  Database  records. 

d.  All  of  the  transaction  data  is  static. 

e.  The  input  transaction  file  is  a temporary  disc  file  that 
requires  one  3330  disc  track  per  156  input  records. 

f.  The  sequence  within  the  individual  files  is  determined 
by  utility  sorts  and  will  be  listed  below. 

Ai:  Ascending  on  V.r-  A 1 - WATCH  STATION 

Dl;  Ascending  on  W-B1-ROCNO 

Cl:  Descending  on  W-Cl-IDEIJT,  Ascending  on  W-Cl-CLASS,  W-C1-UIC 

Dl:  Ascending  on  V.’-Dl-CONDITION 

FI:  Ascending  on  W-F1-SHIPID,  W-Fl-LEVELID 


Data  Environment 

The  purpose  of  W-MONTH-TABLE  is  to  provide  abbreviations 
for  the  twelve  months  in  order  to  include  the  alpha  month  on 
report  headings.  The  table  values  arc  hard-coded  in  the  program. 
The  subscript  used  to  access  the  table  is  W-MM-IND.  W- ERROR- 
MESSAGES  holds  comments  that  are  printed  on  an  error  report  to 
identify  incorrect  data  on  the  input  transactions.  The  subscript 
used  to  access  flic  tabic  is  W-CRD-KERS. 
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Note.:  Throughout  the  program  whenever  the  Database  ir.  accor::;cu , 

the  error  status  field  is  examined.  When  the  value  of  the 


error  status  indicates  a problem,  an  error  routine  is  per- 
formed, edit  totals  are  printed,  and  processing  is  ended. 

This  logic  will  not  be  included  in  the  description  below. 

Program  processing  begins  with  all  files  being  opened,  and 
database  areas  being  made  ready.  Headers  and  print  areas  arc 
initialized,  and  then  file  processing  begins. 

When  an  input  transaction  (will  refer  to  input  transaction 
as  'card')  is  read,  all  of  the  card  data  except  card  type  is 
moved  into  Working  Storage . The  card  type  is  then  examined,  and 
.a  branch  is  made  to  appropriate  edit  routine . 

If  the  card  type  is  'Al',  the  processing  is  as  follows:  The 

Natchstation  number  is  compared  to  the  last  one  read.  If  the  two 
arc  equal,  indicating  duplicates,  an  error-  message  is  stored.  If 
the  Major  Functional  /vrea  is  not  numeric,  an  error  message  is 
stored.  If  Minor  functional  Area  is  not  numeric  and  equals  spaces, 
the  spaces  are  replaced  with  zeros.  If  it  is  not  numeric  and 
does  not  equal  spaces,  an  error  message  is  stored.  If  the 
sequence  code  equals  spaces,  they  are  replaced  with  zeros.  If  it 
is  not  numeric,  an  error  message  is  stored.  If  the  Minor  Functional 
Area  equals  zeros  and  Sequence  code  does  not  equal  zeros,  an  error 
message  is  stored.  If  the  Watchstation  title  is  not  present,  an 
error  message  is  stored.  An  accumulator  for  'Al'  cards  read  is 
incremented.  If  there  were  no  card  errors  a routine  to  load  the 
database  is  performed  (this  will  be  described  later) , and  the 
Watchstation  number  is  stored.  If  card  errors  were  found,  a 
routine  to  print  error  messages  i:.  performed  (described  later).  The 
program  now  branches  to  read  another  card. 

If  the  card  type  is  'Bl',  the  processing  is  as  follows:  the 

ROC  number  is  compared  to  the  last  one  read.  If  the  two  are  equal, 
<m  error  message  is  stored.  If  the  ROC  number  is  not  numeric,  an 
error  message  is  stored.  If  the  Mission  Area  is  blank,  an  error 
message  is  stored.  If  the  Mission  Area  is  not  alphabetic,  an  error 
message  is  stored.  If  the  Operational  Capability  Code  is  missing, 
an  error  message  is  stored  and  there  is  a branch  to  a routine  to 
edit  the  Required  Functional  Capability  (RFC)  Code.  If  the  Oper- 
ational Capability  Code  is  numeric,  but  not  right  justified,  an 
error  message  is  stored  and  there  is  a branch  to  a routine  to  edit 
RFC  code.  If  the  Operational  Capability  code  is  right  justified, 
but  not  numeric,  an  error  message  is  stored.  If  the  RFC  is  numeric 
or  equals  spaces  there  is  a brand)  to  an  end  of  edit  routine.  If 
RFC  code  is  numeric  but  not  fight  justified,  an  error  message  is 
stored,  and  there  is  a branch  to  an  end  of  edit  routine.  If  RFC 
code  is  left  justified  and  not  numeric,  an  error  message  is  stored 
and  there  is  a branch  to  an  end  of  edit  routine.  If  the  RFC  code 
is  right  justified  and  numeric  there  is  a branch  to  an  end  of  edit 
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rouLun:,  othe:  wise  an  error  mcssaue  is  stored.  An  accumulai  or  for 
'nl1  cards  read  is  inert  mented.  If  there  wore  no  card  error::,  a 
routine  to  load  the  database  is  performed  and  the  ROC  number  is 
stored.  If  card  errors  were  found,  a routine  to  print  error  messages 
is  performed.  The  program  now  branches  to  read  another  card. 

If  the  card  type  is  'Cl'  tha  processing  is  as  follows:  If  the 

record  identifier  is  'CLS'  and  the  class  is  equal  to  the  class  in 
hold,  an  error  message  is  stored.  If  the  record  identifier  is  blank 
and  the  ship  is  equal  to  the  ship  ID  in  hold,  an  error  message  is 
stoi’ed.  If  class  is  not  numeric  an  error  message  is  stored.  If  the 
• ship  ID  is  blank,  an  error  message  is  stored.  If  the  record  identi- 
fier is  not  equal  to  either  'CLS'  or  spaces,  an  error  message  is  stored. 
If  chiphull  is  blank,  an  - rror  message  is  stored,  and  if  ship  name 
is  blank.,  an  error  message  is  stored.  An  accumulator  for  'Cl'  cards 
read  is  incremented.  If  there  were  no  card  <.  rors,  a routine  to 
load  the  database  is  performed  and  the  ship  number  is  stored.  If 
card  errors  were  found,  a routine  to  print  error  messages  is  per- 
formed. The  program  now  branches  to  read  another  card. 

Ilf  the  card  type  is  'Dl',  the  processing  is  as  follows:  The 

condition  is  compared  to  the  condition  in  hold.  If  the  two  are 
. equal,  an  error  message  is  stored.  If  the  condition  title  is  blank, 

an  error  message  is  stored.  An  accumulator  for  'D1‘  cards  read 
' is  incremented.  If  thcic  were  no  card  errors,  a routine  to  load 
• the  database  is  performed  and  the  condition  is  stored.  If  card 
errors  were  found,  a routine  to  print  error  messages  is  performed. 

The  program ‘now  branches  to  read  another  card.  • . 

. If  the  card  type  is  'FI',  the  processing  is  as  follows:  The 

level  and  ship  code  are  compared  to  the  level  and  ship  values  that 
have  been  stored.  If  they  are  both  equal  to  the  respective  values 
. in  hold,  an  error  message  is  stored.  If  the  level  is  blank,  an 
error  message  is  stored.  If  the  level  name  is  blank,  an  error 
message  is  stored.  If  the  ship  code  is  not  nvmeric,  an  error 
message  is. stored.  An  accumulator  for  'FI*  records  read  is  incre- 
mented. If  no  card  errors  were  detect. .d,  a routine  to  load  the 
database  is  performed;  ship  code  and  level  are  stored.  If  card 
errors  were  found,  a routine  to  print  error  messages  is  performed. 

The  program  now  branches  to  read  another  card. 

The  following  is  the  logic  for  the  routine  to  print  error 
messages:  If  the  line  count  exceeds  43,  a routine  to  begin  a 

new  page  is  performed.  The  input  transaction  is  moved  to  the 
print  line  and  is  printed.  The  card  is  underlined  and  another 
line  is  printed  with  spaces.  The  line  count  is  incremented. 

There  is  a loop  to  print  the  error  messages:  A subscript  (W-ERR- 
IR’D)  is  incremented  by  one.  If  the  subscript  is  greater  than  the 
number  of  errors  that  occurred  (W-CRD-ERR5) , the  loop  is  ended. 

There  is  a routine  performed  to  determine  whether  to  go  to  a new 
page  and  print  headings  if  necessary.  An  error  message  is  moved 
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from  a table  JUT-unr)  ; o print,  line  and  .in  printed.  The  .Uni* 
count  in  increm. -mod . 'men  there  i a branch  ho  the  begi nni  n>j  of 
file  loop  which  continue::  until  all  error  messages  are  printed. 

Once  out  of  tin:  loop,  an  accumulator  for  card  type  errors  is 
incremented,  two  lines  of  spaces  are  printed,  the  table  that  held 
massages  end  the  area  that  held  the  card  in  error  are  cleared, 
and  the  subscript  and  the  error  counter  arc  rc-initialized  to 
zero . 

The  header  routine  sots  the  line  count  back  to  zero  and  adds 
1 to ’ the  page  counter.  It  then  prints  headings  on  a new  page  by 
moving  to  the  print  line  headers  that  are  set  up  in  Working 
Storage  and  printing  them  one  by  one. 

The  line  check  routine  checks  to  see  if  the  line  count  is 
greater  than  4G,  and  if  it  is,  the  header  routine  is  performed. 

The  routine  to  print  a line  simply  writes  the  line  and  then 
rc-initializes  the  print  line  to  spaces. 

The  following  paragraphs  will  describe  the  routines  to  load 
data  onto  the  database.  The  card  types  are  checked,  and  a branch 
is  made  to  the  appropriate  load  routine,  or  the  program  falls  into 
the  routine  to  load  a WS'flTLE  record  when  the  card  type  is  ' A1 ' 
which  follows:  Data  is  moved  from  the  card  to  tlic  appropriate 

V7STITLE  fields  in  Working  Storage,  and  then  the  record  is  stored. 
If  the  record  is  a duplication  of  a record' that  already  exists,- 
an  error  message  is  stored  and  the  program  branches  to  an  exit 
routine.  The  record  that  was  added  is  displayed,  then  there  is  a 
branch  to  an  exit  routine.  ' .. 

If  the  record  type  is  'Bl'  the  following  process  loads  a 
noCTlTLB  record.  Data  is  moved  from  the  c£ird  tc  the  appropriate 
KOCTITLE  fields  in  Working  Storage,  then  the  record  is  stored. 

If  the  error  status  indicates  that  thi s -record  is  a duplication 
of  one  that  already  exists,  an  error  message  is  stored  and  the 
program  branches  to  an  exit  routine.  If  the  record  is  added 
successfully,  it  is  displayed  and  there  is  a branch  to  an  exit 
routine. 

If  the  card  type  is  'Cl',  either  a CLASS  or  SHIP  record  may 
be  loaded.  The  processing  is  as  follows:  If  the  record  identifi 

cris  'CLS',  there  is  a branch  to  the  'CLASS'  load  routine.  The 
class  is  used  to  obtain  the  CLASS  record  owner  of  the  CLASS-SHIP 
set  to  which  the  SHIP  will  be  added.  If  the  CLASS  record  is  not 
found,  an  error  message  is  stored  and  there  is  a branch  to  an 
exit  routine.  If  the  CLASS  record  is  found  successfully,  the 
ship  data  is  moved  from  the  card  into  the  appropriate  SHIP  record 
fields  in  Working  Storage,  and  the  new  SHIP  record  is  stored. 

.The  record  is  automatically  linked  to  its  CLASS  owner.  If  the 
error  status  indicates  a duplicate,  an  error  message  is  stored, 
and  there  is  a branch  to  an  exit  routine.  If  the  record  is 
added  successfully,  it  is  displayed  and  there  is  a branch  to  an 
exit  routine. 
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-aid  tlie  new  CLASS  record  i stored.  If.  Die  orlor 
status  indic-itc.-G  a duplicate,  an  error  nic.-GGacjo  is  stored  and  there 
is  a bi  aiich  to  an  exit  routine*  If  the  record  is  added  succcssf  ulJ  y , 
it  is  displayed  and  then  there  is  a branch  to  an  exit  routine. 


If  the  card  type  is  ' Dl'  a COiiDTITLK  record  is  to  be  added  and 
the  processing  is  as  follov/s:  The  card  data  is  moved  into  the 
C0NDT1TLC  record  fields  in  Working  Storage  and  the  record  is  stored. 
If  the  error  status  indicates  a duplicate,  an  error  message  is 
stored  and  there  is  a branch  to  an  exit  routine.  If  the  record  is 
added  successfully,  it  is  displayed  and  there. is  a branch  to  an 
exit  routine. 

If  the  card  type  is  'll'-,  a LEVEL  record  is  to  be  added  and 
the  processing  is  as  follows:  The  ship  on  the  card  is  used  to 

obtain  the  SHIP  record  owner  of  the  SHIP-LEVEL  set  to  which  the 
LEVEL  record  is  to  be  added.  If  the  SHIP  record  is  not  found, 
an  error  message  is  stored,  and  there  is  a branch  to  an  exit  routine. 
If  the  SHIP  is  located  successfully,  the  level  data  is  moved  from  the 
card  into  the  LEVEL  record  fields  in  Working  Storage  and  the  record 
is  stored.  If  the  error  status  indicates  a duplicate , an  error 
message  is  stored  and  there  is  a branch  to  an  exit  routine.  If  the. 
record  is  added  successfully,  it  is  displayed  and  there  is  a branch 
to  an  exit  routine. 

The  database  error  routine  is  performed  whenever  an  error  status 
that  indicates  a problem  is  returned.  The  card  being  processed  is 
displayed,  along  with  the  error  status  and  ;:n  indicator  that  locates 
the  paragraph  where  the  problem  occurred.  It  branches  to  the 
routine  to  print  edit  totals. 

The  update  exit  routine  checks  to  see  if  any  errors  occurred 
during  the  load  routine.  If  there  were  none,  the  database  key  of 
Die  record  j use  added  is  displayed,  an  accumulator  for  transactions 
added  is  incremented  for  the  appropriate  card  type,  and  the 
program  falls  into  the  routine  to  print  edit  totals.  If  errors  did 
occur,  the  routine  to  print  error  messages  is  performed,  and  the 
program  falls  into  the  routine  to  print  edit  totals. 

The  routine  to  print  edit  totals  loops  through  a table  where  the 
totals  are  stored  (W-CTRl-'J'ABLE)  . Before  the  loop  begins,  headers 
arc  printed  on  a new  page.  The  loop  is  as  follows:  h subscript 

(W-TYPE-iND)  to  identify  the  card  type  is  incremented.  If  the 
subscript  is  greater  than  5 (only  five  card  types) , the  subscript 
is-  reinitialized  to  zero  and  there  is  a branch  to  an  end  of  program 
routine.  Another  subscript  (W-CTR-IKD)  is  incremented  (lor  the 
totals).  If  the  subscript  is  greater  than  3,  it  is  ro- .initial  i zed 
to  zero  and  there  is  a branch  to  print  the  line.  The  data  fro:  Die 

table  is  moved  to  the  print  line  and  printed.  Then  there  is  a branch 
to  the  beginning  of  the  loop.  The  loop  continues  until  all  the  edit 
totals  arc  printed. 

The  last  paragraph  closes  all  files,  closes  the  database  areas, 
and  ends  program  processing. 
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This  module  updates  (adds,  changes,  and  deletes)  the 
types  on  tiie  Chip  ROC/V.'atchstal  ion  Module  Database: 


class,  s::: j i> ,' 

number  11-0001 


no  CGNLTITLE.  The  program  was  written 
-7 G-C-0-'. 7 3 , effective  24  November  1975 


following  record 
WSTITLE,  KOC TITLE , 
under  contract 


S uj >por t So f tware  Envi  ronnie n t 


'I'll i s module  of  the  NMRS  must  be  written  in  standard 


This  language 
can  National 


Common  Business  Oriented  Language  (COBOL) 
described  in  detail  in  the  IBM  OS  Full  Am. 

Standard  COBOL  manual.  No  IBM  extensions  ( d o si gnaTecf ’by 
shaded  background  in  the  COBOL  manual)  may  be.  used  in  the 
programming  of  this  module.  The  allowable  exceptions  are 
the  CALL,  CANCEL,  USING  and  GOBACK  statements  and  the  use 
the  linkage  section  to  transfer  parameters  during  the 
execution  of  the  CALL. 


oi. 


b.  The  general  software  environment  is  dependent  upon 
the  hardware  configuration  on  which  the  NMRS  is  operating. 
The  available  software  at  NIH  is  listed  in  the  Nil!  Computer 
Center  Users  Guide. 


Inputs 

Input  to  NMWBO 1 may  be  any  or  all  of  five  different  types  of  input 
transactions.  The  input  file  is  described  in  the  Characteristics 
paragraph  below. 


Outputs 

Output  from  NMWB01  may  be  any  or  all  of  five  different  typos  of 
Ship/ROC  Database  records,  namely  WSTITLE,  ROCTITLE,  CLASS,  SLIP, 
and  CONDTITLE. 

Working  Storage 

Working  storage  consists  of  report  headers  and  detail  line  formats; 
tables  used  for  accumulating  totals,  printing  reports,  and  convoi Ling 
data;  accumulators  for  various  totals;  and  subscripts  used  in  asses- 
• sing  table  elements. 

Characteristics 


A.  IT-REC  is  the  card  input  transaction.  The  file  is  a concat 
enation  of  up  to  four  individual  files  that  are  output  from 
utility  sorts. 
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B.  Each  input  transaction  is  edited  according  to  specifications  for  the 
particular  record  type  associated  with  the  transaction.  If  the 
record  contains  valid  data,  the  transaction  is  used  to  update 
a particular  Database  record;  otherwise  the  transaction  is 
printed  on  an  error  report  where  the  invalid  card  data  is 
identified . 

C.  The  data  in  the  transaction  header  identifies  the  type  of  trans- 
action, and  the  Database  record  type  with  which  it  is  associated 
The  record  key  is  used  to  either  locate  the  Database  record  to 
be  modified  or  deleted  or  place  the  Database  record  to  be  added. 
The  text  is  used  to  modify  or  build  a Database  record. 


D.  All  of  the  transaction  data  is  static. 

E.  The  input  transaction  file  is  a-  temporary  disc  file  that  re- 
quires one  3330  disc  track  per  156  input  records. 

F.  The  input  files  may  be  concatenated  in  any  order.  The  sequence 
within  the  files  is  determined  by  utility  sorts  and  will  be 
listed  below. 

A1 : . Descending  on  function,  ascending  on  W-Al-VJSID. 

B1 : Descending  on  function,  ascending  on  W-Bl-SOCTD. 

Cl:  Ascending  on  card  type,  descending  on  function, 

Ascending  on  W-C1-CLASSID/W-C2-SHIPID . 

Dl:  Descending  on  function,  ascending  on  W-Dl-CONDITION. 

G.  The  Database  Administrator  should  approve  all  changes,  deletions, 
and  additions  to  the  Database  submitted  through  this  module. 

All  the  files  updated  by  this  module  are  used  as  "dictionary" 
files  to  validate  data  input  to  NMWB02  to  update  all  other 
Database  files.  Actual  restrictions  built  into  the  module 
are : 

(1)  A CLASS  record  may  not  be  deleted  until  all  of  its 
member  SHIP  records  have  been  deleted. 

(2)  A new  CLASS  and  its  new  SHIP  members  may  be  added  in 
the  same  run,  but  a CLASS  and  its  SHIP  members  may  not 
be  deleted  in  the  same  run. 

Data  Environment 

The  purpose  of  W- MONTH -TABLE  is  to  provide  abbreviations  for  the 
twelve  months  in  order  to  include  the  alpha  month  on  report  headings. 
The  table  values  are  hard-coded  in  the  module.  W-ERROR-MESSAGKS 
holds  comments  that  are  printed  on  an  error  report  to  identify  in- 
correct data  on  the  input  transactions.  The  subscript  used  to  access 
the  tabic  is  W-CRD-ERRS. 

' 


Note:  Throughout  * ho  program  whoncvor  the  dnt  abase  if?  accessed , 

the  error  status  field  is  examined.  When  the  value  of:  the 
error  status  indicates  a problem,  an  error  routine  is  per- 
formed, edit  totals  are  printed,  and  processing  is  ended. 

This  logic  will  not  be  included  in  the  description  below. 

Program  processing  begins  with  all  files  being  opened,  and  database 
areas  being  made  ready.  Headers  and  print  areas  are  initialized, 
and  then  file  processing  begins. 

When  an  input  transaction  (will  refer  to  inpit  transaction  as  ‘card’] 
is  read,  all  of  the  card  data  except  card  type  is  moved  into  Working 
Storage.  The  card  type  is  then  examined,  and  a branch  is  made  to  an 
appropriate  edit  routine. 

If  the  card  type  is  'Al',  the  processing  is  as  follows:  An  accu- 

lator  for  Al  cards  read  is  incremented.  If  the  Major  Functional 
Area  is  not  numeric,  an  error  message  is  stored.  If  Minor  Function- 
al Area  is  not  numeric  and  equals  spaces,  the  spaces  are  replaced 
with  zeros.  If  it  is  net  numeric  and  does  not  equal  spaces,  an 
error  message  is  stored.  If  the  sequence  code  equals  spaces,  they 
are  replaced  with  zeros.  If  it  is  not  numeric,  an  error  message  is 
stored.  If  the  Minor  Functional  Area  equals  zeros  and  Seqence 
code  does  not  equal  zeros,  an  error  massage  is  stored.  If  the  card 
function  is  'D'  the  editing  is  complete  and  one  of  two  paths  may  be 
followed:  If  there  were  no  card  errors  to  this  point,  there  is  a 
branch  to  the  routine  to  delete  WST1TLE  records.  If  errors  wore 
found,  there  is  a branch  to  an  end  of  transaction  routine.  If  card 
type  is  not  'D',  editing  continues.  If  the  Watcbstation  Title  is 
not  present,  an  error  message  is  stored.  If  the  card  function  is 
not  'A',  or  'C1,  or  'D'  an  error  message  is  stored.  Editing  is 
now  compxcte.  Now  if  card  errors  occurred  there  is  a branch  to  an 
end  of  transaction  routine.  If  no  errors  occurred,  there  is  either 
a branch  to  the  change  WSTITLE  routine  if  function  is  'C';  or  the 
program  drops  into  the  add  WSTITLE  routine. 

The  processing  to  add  a WSTITLE  record  is  as  follows:  The  WSTITLE 

card  data  is  moved  into  the  appropriate  WSTITLE  record  fields  in 
Working  Storage  and  the  record  is  stored.  If  the  error  status 
indicates  a duplicate,  an  error  message  is  stored  and  there  is  a 
branch  to  an  end  of  transaction  routine.  If  the  record  is  added 
successfully,  an  accumulator  for  WSTITLE  records  added  is  incre- 
mented, the  record  and  its  database  key  are  displayed,  and  there  is 
c?  branch  to  an  end  of  transaction  routine. 


The  change  routine  for  a WSTITLE  record  follows:  There  is  an 

attempt  to  obtain  the  record  to  be  changed.  If  the  error  status 
indicates  that  the  record  docs  not  exist,  an  error  message  is 
stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  record  is  found,  card  data  is  moved  into  the  appropriate 
WSTITLE  record  fields  in  working  storage  and  the  record  is  modified. 
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changed  is  incremented,  the  record  and  its  database  key  are  dis- 
played, and  there  is  a branch  to  an  end  ol  transaction  loutinc. 

The  processing  to  delete  a WSTITLK  record  is  as  follows:  There 

is  an  attempt  to  obtain  the  record  to  be  deleted.  If  th  > < r.  su- 
stains indicates  that  the  record  does  not  exist,  an  error  message 
is  stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  record  is  found,  it  is  erased.  If  the  operation  is  success- 
ful, an  accumulator  for  WSTITLE  records  deleted  is  incremented  and 
the  program  drops  into  the  end  of  transaction . routine . 

The  end  of  transaction* routine  follows:  If  card  errors  were  found, 

a routine  to  print  er”or  messages  is  performed.  Then  there  is  a 
branch  back  to  the  read  paragraph. 

If  the  card  type  is  1 Bl ' , the  processing  is  as  follov.’s:  An  accumu- 

lator for  Bl  transactions  read  is  incremented.  If  the  ROC  number 
is  not  numeric,  an  error  message  is  stored.  If  the  function  is 
'D',  there  is  no  more  editing  and  one  of  two  branches  are  made: 

If  there  were  no  card  errors,  there  is  a branch  to  the  ROCTITI.E 
delete  routine;  if  there  were  errors  there  is  a branch  to  an  end 
of  transaction  routine.  If  the  Mission  Area  is  blank,  an  error 
message  is  stored.  If  the  Mission  Area  is  not  alphabetic,  an 
error  message  is  stored.  If  the  Operational  Capability  Code  is 
missing,  an  error  message  is  stored  and  there  is  a branch  to  a 
routine  to  edit  the  Required  Functional  Capability  (RFC)  Code.  If 
the  Operational  Capability  Code  is  numeric,  but  not  right- justified, 
an  error  message  is  stored  and  there  is  a branch  to  a routine  to 
edit  the  RFC  code.  If  the  Operational  Capability  code  is  right- 
justified,  but  not  numeric,  an  error  message  is  stored.  If  the 
RFC  is  numeric  or  equals  spaces  there  is  a branch  to  end  of  edit 
routine.  If  RFC  code  is  left- justified  and  not  numeric,  an  error 
message  is  stored  and  there  is  a branch  to  an  end  of  edit  routine. 

If  the  RFC  code  is  rigjjjj:- j ustif ied  and  numeric  there  is  a branch 
to  an  end  of  edit  rouiffne,  otherwise  an  error  message  is  stored. 

If  the  card  function  is  not  'A',  or  ' C,  or  'D',  an  error  message 
is  stored.  The  editing  is  now  complete.  If  card  errors  were 
found  there  is  a branch  to  an  end  of  edit  routine.  If  the  data 
was  correct  there  is  a— branch  to  a change  routine  if  the  function 
is  ' C',  or  the  program  drops  into  the  add  routine  for  ROCTITLE 
records. 

The  ROCTITLE  record  add  routine  follows:  The  card  data  is  moved 

into  the  appropriate  ROCTITLE  record  fields  in  Working  Storage  and 
the  record  is  stored.  If  the  error  status  indicates  a duplicate, 
an  error  message  is  stored  and  there  is  a branch  to  an  end  of 
transaction  routine.  If  the  record  is  added  successfully,  an 
accumulator  for  ROCTITLE  records  added  is  incremented,  the  record 
and  its  database  key  are  displayed  and  there  is  a branch  to  an 
end  of  transaction  routine. 
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indicator,  tint  the  record  door,  not  exist,  an  error  men  sane  in 
stored  and  there  is  a branch  to  an  end  of  transaction  routine.  If 
the  record  in  found,  the  card  data  is  moved  into  the  appropriate 
ROCTITLE  record  field.;  in  Working  Storage  and  the  record  i s modifier 
If  the  operation  is  successful , an  nceu..snJ  a ten  for  ROCTTTj  •:  records 
changed  is  incremented,  the  record  and  its  database  key  are  dis- 
played, and  there  is  a branch  to  an  end  of  edit  routine. 


The  routine  to  delete  a ROCTITLE  record  is  as  follows:  There 

an  attempt  to  obtain  the  record  to  be  deleted.  If  the  error  s 
indicates  that  the  record  does  not  exist,  an  error  message  is 
stored  and  there  is  a branch  to  an  end  of  transaction  routine, 
the  record  is  found,  it  is  erased.  If  the  operation  is  succor, 
an  accumulator  for  ROCTITLE  records  deleted  is  incremented  and 
program  drops  into  the  end  of  transaction  routine. 
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The  end  of  transaction  routine  follows:  If  card  errors  were  found, 

a routine  to  print  error  messages  is  performed.  Then  there  is  a 
branch  back  to  the  read  paragraph. 


If  the  record  type  is  'C21,  the  processing  is  as  follows.  An 
accumulator  for  C2  transactions  read  is  incremented.  If  the 
Ship  code  is  not  present,  an  error  message  is  stored.  If  the 
class  code  is  not  numeric  an  error  message  is  stored.  If  the 
card  function  is  'D'  the  editing  is  complete  and  one  of  tv/o  paths 
may  be  followed:  If  there  were  no  card  errors  to  this  point, 

there  is  a branch  to  the  routine  to  delete  SHIP  records.  If 
errors  were  found,  there  is  a branch  to  an  end  of  transaction 
routine.  If  iihe  card  function  is  not  'O',  editing  continues.  If 
identif ication  is  missing,  an  error  message  is  stored.  If  the 
ship  name  is  missing  an  error  message  is  stored.  If  the  card 
function  is  not  'A',  or  'C',  or ' ' V an  error  message  is  stored. 
Editing  is  now ' complete . Nov;  if  card  errors  occurred  there  is  a 
branch  to  an  end  of  transaction  routine.  If  no  errors  occurred, 
there  is  cither  a branch  to  the  change  SHIP  routine  if  function 
is  ' C',  or  the  program  drops  into  the  add  SHIP  routine. 


The  processing  to  add  a SHIP  record  is  as  follows:  There  is  an 

attempt  to  obtain  the  CLASS  owner  record  of  the  CLASS-SHIP  set 
to  which  the  SHIP  is  to  be  added.  If  the  error  status  indicates 
that  the  record  docs  not  exist,  an  error  message  is  stored  and 
there  is  a branch  to  an  end  of  transaction  routine.  If  the  re- 
cord is  found,  the  SHIP  data  from  the  card  is  moved  into  the 
appropriate  SHIP  fields  in  Working  Storage  and  the  new  SHIP  record 
is  stored.  If  the  error  status  indicates  a duplicate,  an  error 
message  is  stored  and  there  is  a branch  to  an  end  of  transaction 
routine.  If  the  record  is  added  successfully,  an  accumulator  for 
SHIP  record  is  incremented,  the  record  and  its  database  key  are 
displayed,  and  there  is  a branch  to  an  end  of  transaction  routine. 
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attempt  to  obtain  the  SHIP  record  to  be  chanejod.  .If  the  error 
status  indicates  the*  record  does  not  exist,  an  error  i;;e:  is 

stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  record  is  found,  there  is  an  attempt  to  obtain  the  CLASS 
owner  record  within  the  SHIP'S  CLASS-SHIP  set.  If  the  owner  is 
found,  it;  is  compared  to  the  class  field  on  the  card.  If  the 
two  are  not  equal,  an  error  message  is  stored  and  there  is  a 
branch  to  an  end  of  transaction  routine.  If  they  are  equal,  the 
currency  of  the  SHIP  record  to  be  changed  is  re-established  and 
change  processing  continues.  Card  data  is  moved  into  the  appropri- 
ate SHIP  record  fields  in  Working  Storage  and  the  record  is  modi- 
fied. If  the  operation  is  successful,  an  accumulator  for  SHIP 
records  changed  is  incremented,  the  record  and  its  database  key 
are  displayed,  and  there  is  a branch  to  an  end  of  transaction 
routine. 


The  delete  routine  for  SHIP  records  follows : There  is  an  attempt 

to  obtain  the  SHIP  record  to  be  deleted.  If  the  error  status 
indicates  the  record  does  not  exist,  an  error  message  is  stored 
and  there  is  a branch  to  an  end  of  transaction  routine.  If  the 
record  is  found,  there  is  an  attempt  to  obtain  the  CLASS  owner 
record  within  the  SHIP'S  CLASS-SHIP  set.  If  the  owner  is  found, 
it  is  compared  to  the  class  field  on  the  card.  If  the  two  are  ' 
not  equal,  an  error  message  is  stored  and  there  is  a branch  to  an 
end  of  transaction  routine.  If  they  are  equal,  the  currency  of 
the  SHIP  record  is  established  and  it  is  erased.  If  the • operation 
is  successful,  an  accumulator  for  SHIP  records,  deleted  is  incre- 
mented and  the  program  drops  into  the  end  of  transaction  routine. 

Tiie  end  of  transaction  routine  follows:  If  card  errors  were  found, 

a routine  to  print  error  messages  is  performed.  Then  there  is  a 
branch  back  to  the  read  paragraph. 

If  the  card  type  is  'Cl'  the  processing  is  as  follows:  An  accumu- 

lator for  Cl  cards  read  is  incremented.  If  class  code  is  not 
numeric,  an  error  message  is  stored.  If  the  function  is  'D',  there 
is  no  more  editing  and  one  of  two  branches  is  made:  If  there 

were  no  card  errors,  there  is  a branch  to  the  CLASS  delete  routine; 

if  there  were  errors  there  is  a branch  to  an  end  of  transaction 

routine.  If  function  is  not  'D',  editing  continues.  If  ship 
code  is  not  present,  an  error  message  is  stored.  If  card  function 
is  not  'A',  or  ’C,  or  ' D ' an  error  message  is  stored.  If  card 

errors  were  found  there  is  a branch  to  an  end  of  edit  routine.  If 

the  data  was  correct,  there  is  a branch  to  a change  routine  if  the 
function  is  'C',  or  the  program  drops  into  the  add  routine  for 
C Lft S S records. 

The  processing  to  add  a CLASS  record  is  as  follows:  The  CLASS 

card  data  is  moved  into  the  appropriate  CLASS  record  fields  in 
Working  Storage  and  the  record  is  stored.  If  the;  error  status 
indicates  a duplicate,  an  error  message  is  stored  and  there  is  a 
branch  to  an  end  of  transaction  routine.  If  the  record  is  added 
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Tho  routine  to  change  a CLASS  record  follows:  There  is  an  attor.ipt 

to  obtain  tho  record  to  be  changed.  If  the  error  status  indicates 
that  tiie  record  does  not  exist  an  error  message  is  stored  :.d 
there  is  a branch  to  an  end  of  transaction  routine.  if  Lir-  record 
is  found,  card  data  is  moved  into  the  appropriate  record  fields  in 
Working  Storage  and  tho  record  is  modified.  If  the  operation  is 
successful,  an  accuse; lator  for  CLASS  records  changed  is  incremented, 
the  record  and  its  database  key  are  displayed,  and  there  is  a 
branch  to  an  end  of  transaction  routine. 

The  processing  to  delete  a CLASS  record  is  as  follows:  There  is 

an  attempt  to  obtain  the  record  to  bo  deleted.  If  the  error 
status  indicates  that  the  record  does  not  exist,  an  error  message 
is  stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  record  is  found,  it  is  erased.  If  the  operation  is  success- 
ful, an  accumulator  for  CLASS  records  deleted  is  incremented  and 
the  program  drops  into  the  end  of  transaction  routine. 


The  end  of  transaction  routine  performs  a routine  to  print  error 
messages  if  the  card  had  errors  and  then  branches  back  to  the  read 
paragraph . 

If  the  card  type  is  ’ D1 1 the  processing  is  as  follows:  An  accumu- 

lator for  D1  records  rend  is  incremented.  If  the  condition  is 
spaces,  an  error  message  is  stored.  If  function  is  ’D’  and 
there  is  no  error  so  far,  there  is  a branch  to  a delete  CONDTITLE 
records  routine.  If  function  is  1 D * and  data  is  incorrect,  there 
is  a branch  to  an  end  of  transaction  routine.  If  condition  title 
is  missing,  an  error  message  is  stored.  If  card  function  is  not 
’A1,  ’C'  or  'D1  an  error  message  is  stored.  The  editing  is  now 

complete.  If  card  errors  were  found  there  is  a branch  to  an  end 
of  edit  routine.  If  the  data  was  correct,  there  is  a branch  to 
a change  routine  if  tne  function  is  'C';  or  the  program  drops 
into  the  add  routine  for  CONDTITLE  records. 

The  CONDTITLE  record  add  routine  follows:  The  card  data  is  moved 

into  the  appropriate  CONDTITLE  record  fields  in  Working  Storage 
and  the  record  is  stored.  If  the  error  status  indicates  a duplicate, 
an  error  message  is  stored  and  there  is  a branch  to  an  end  of 
transaction  routine.  If  the  record  is  added  successfully,  an 
accumulator  for  CONDTITLE  records  added  .is  incremented,  the  record 
and  its  database  key  are  displayed,  and  there  is  a branch  fo  an 
end  of  transaction  routine. 


The  .logic  for  changing  a CONDTITLE  record  is  as  follows:  There 

is  an  attempt  to  obtain  the  record  to  be  changed.  If  the  error 
status  indicates  that  the  record  docs  not  exist,  an  error  message 
is  stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  record  is  found,  tho  card  data  is  moved  into  the  appropriate 
CONDTITLE  record  fields  in  Working  Storage  and  tho  record  is 
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modified.  If  the  operation  is  successful,  an  accumulator  for 
CONDTITLE  records  changed  is  incremented,  the  record  and  its 
database  key  are  displayed,  and  there  is  a branch  to  an  end 
of  edit  routine. 

Tho  processing  to  delete  a CCVJ0T1 TEE  record  is  as  follow::  Theta- 

is  an  attempt  to  obtain  the  record  to  be  deleted.  If  Die  error 
status  indicates  that  the  record  docs  not  exist,  an  error  mes- 
sage is  stored  and  there  is  a branch  to  an  end  of  transaction 
routine.  If  the  record  is  found,  it  is  erased.  If  the  operation 
is  successful,  an  accumulator  for  CONDTITI.E  records  deleted  is 
incremented  and  the  program  drops  into  the  end  of  transaction 
routine. 


The  end  of  transaction  routine  performs  a routine  to  print  error 
messages  if  errors  were  found  and  then  branches  jack  to  the  read 
paragraph . 


The  database  error  routine  is  performed  whenever  an  error  status 
that  indicates  a problem  is  returned.  The  card  being  processed  is 
displayed,  along  with  the  error  status  and  an  indicator  that 
locates  the  paragraph  where  the  problem  occurred.  It  branches 
to  the  routine  to  print  edit  totals. 


The  following  is  the  logic  for  the  routine  to  print  error  messages: 
If  the  line  count  exceeds  4G,  a routine  to  begin  a new  page  is 
performed.  The  input  transaction  is  irioved  to  the  print  lino  and  is 
printed.  The  card  is  underlined  and  another  line  is  printed  with 
spaces.  The  line  count  is  incremented.  There  is  a loop  to  print 
the  error  messages:  A subscript  (W-ERR-IND)  is  incremented  by  one. 

If  the  subscript  is  greater  than  the  number  of  errors  that 
occurred  (W-CRD-ERRS)  , the  loop  is  ended.  There  is  a routine  per- 
formed to  determine  whether  to  go  to  a new  page  and  print  heading 
if  necessary.  An  error  message  is  moved  from  a table  (W--PRT-ERR) 
to  print  line  and  is  printed.  The  line  count  is  incremented. 

Then  there  is  a branch  to  the  beginning  of  the  loop  which  continues 
until  all  error  messages  are  printed.  Once  out  of  the  loop,  an 
accumulator  for  card  type  errors  is  incremented,  two  lines  of  spaces 
are  printed,  the  table  that  held  messages  and  the  area  that  held 
the  card  in  error  are  cleared,  and  the  subscript  and  the  error 
counter  are  re-initialized  to  zero. 

The.  header  routine  sets  the  line  count  back  to  zero  and  adds  1 to 
the  page  counter.  It  then  prints  headings  on  a new  page  by  moving 
to  the  print  lino  headers  that  are  set  up  in  Working  Storage  and 
printing  them  one  by  one. 

The  line  check  routine  checks  to  see  if  the  line  count  is  greater 
than  46,  and  if  it  is,  the  header  routine  is  performed. 

The  routine  to  print  a line  simply  writes  the  lino  and  then  re- 
initializes the  print  line  to  spaces. 
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(V.’-TYPh-IKD)  to  identify  the  card  type  .is  incremented.  Ti  l he  .'nib- 
script  is  greater  than  5 (only  five  card  types),  the  subscript 
is  re- initialised  to  zero  and  there  is  a branch  to  an  end  oi.  pro- 
gram routine.  Another  subscript  (W-FLD-CTK)  is  inc r onion led  (f.o; 
the  totals).  If  the  subscript  is  greater  than  5,  it  is  re- 
initialized to  zero  and  there  is  a branch  to  print  the  line.  The 
data  from  the  table  is  moved  to  the  print  line  and  printed.  Then 
there  is  a branch  to  the  beginning  of  the  loop.  n’he  loop  continues 
until  all  the  edit  totals  are  printed. 

Tire  last  paragraph  closes  all  files,  closes  the  database  areas,  and 
ends  program  processing. 
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APPENDIX  E 


MDDULE  NMWB02 


E-l 


A 


Modulo  Descri ntion 


This  modulo  updates  (adds,  changes 
typos  on  the  ship  nOC/V.’atchstation 
and  HOC . The  progr;.:n  was  written 
04/3,  effective  24  November  1975. 


, or  deletes)  the  following 
Module  Database:  WS , V.’SP/'-C 

under  contract  number  M-0001 


record 
, LEVEL 
4-75-C- 


Inputs 

Input  to  NMWBO 2 may  any  or  all  of  six  different  types  o.  input 
transactions.  The  input  file  is  described  in  the  Characteristics 

paragraph  be lew. 

Outputs 

Output  from  NMWB02  may  be  any  or  all  of  four  different  types  of 
SHIP/ROC  database  records,  namely  LEVEL,  ROC,  WS,  and  WSROC. 

Working  Storage 


Working  storage  consists  of  report  headers  and  detail  line  formats; 
tables  used  for  accumulating  totals,  printing  reports,  and  convert- 
ing data;  accumulators  for  various  totals;  and  subscripts  used  in 
accessing  table  elements. 

Characteristics 


A.  IT-REC  is  the  card  input  transaction.  The  file  is  a concate- 
nation of  up  to  four  individual  files  that  are  output  from  utility 
sorts . 

B.  Each  input  transaction  is  edited  according  to  specifications 
for  the  particular  record  type  associated  with  the  transaction. 

These  requirements  are  stated  in  the  Module  Specifications.  If  the 
record  contains  valid  data,  the  transaction  is  used  to  update  a 
particular  database  record;  otherwise  the  transaction  is  printed 
on  an  error  report  where  the  invalid  card  data  is  identified. 

C.  The  data  in  the  transaction  header  identifies  the  type  of  trans- 
action, the  function  of  the  transaction,  and  the  database  record 
type  with  which  it  is  associated.  The  record  key  is  used  to  either 
locate  the  database  record  to  be  modified  or  deleted  or  place  the 
database  record  to  be  added.  The  text  is  vised  to  modify  or  build 

a database  record. 

D.  All  of  the  transaction  data  is  static. 

E.  The  input  transaction  file  is  a temporary  disc  file  that  requires 
one  3330  disc  track  per  156  input  records. 
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F.  The  individual  files  must  be  concatenated  in  the  following  order: 
FI,  G1  and  ill,  G5  ami  115,  Jl.  The  sequence:  wi  thin  the  indivic 
files  is  determined  by  utility  sorts  and  will  be  listed  below. 


11:  Descending  on  function,  ascending  on  LEVELKEY.  Cl 
Descending  on  card  type,  descending  on  function,  asccn 
N-IIl~NLkEY . G5  and  115:  Descending  on  card  type,  desc 
function,  ascending  on  W-H5-WSR0C-KEY. 


Cl  end  III: 
ending  on 
;cending"  on 


Jl:  Descending  on  function,  ascending  on  W- Jl-ROCKEY . 


When  changing  a WS  record  that  has  a duplicate  (s)  within 
a set,  the  user  must  be  sure  that  the  complete  V.'S  is  changed. 
Only  one  change  card  may  be  submitted.  This  card  will  change 
the  NS  record  that  is  the  owner  of  a WS-WSROC  set,  if  one 
exists.  In  order  to  change  other  dup] ieates  or  to  have  them 
remain  as  they  are,  add  cards  must  be  submitted  containing 
the  appropriate  data.  Example:  Watchstation  0100100010  occurs 

three  times  within  the  CLASS-WS  set  that  Inns  class  001  as  the 
owner  record.  The  user  wants  to  change  the  watchstsndcf  re- 
quirements for  one  occurrence  of  the  watchstation  and  have  the 
other  duplicates  remain  unchanged.  The  following  cards  must 
bo  submitted:  One  change  card  with  the  new  wntchstandcr  data, 

and  two  add  cards  containing  the  data  currently  on  the  database 
for  the  duplicate  occurrences  of  the  watchstation  which  the 
user  wishes  to  remain  unchanged. 

When  deleting  a WS  record  that  has  a duplicate (s)  in  the 
same  set,  all  occurrences  of  that  watchstation  in  that  set 
will  be  deleted. 


The  same  record  may  be  deleted  and  added  bade  in  one  run. 

When  modifying  WS  and  LEVEL  records  on  the  database,  the 
transaction  that  will  be  used  must  contain  exactly  the 
data  that  is  to  bo  on  the  database  after  the  modification. 
The  particular  field  that  is  to  be  changed  is  not  suf- 
ficient. 
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Note:  Throughout  the  program  whenever  lh< • database  is 

acccr. d , the  error  status  j r.  checked.  V.’lv  n the 
error  status  indicates  a problem,  an  error  rou- 
tine is  performed  and  processing  is  ended.  This 
logic  will  not  be  includes  below. 

Piles  are  opened,  database  areas  are  made  available,  and  print  anus 
are  initialized. 

An  input  transaction  is  read  and  the  input  data  is  stored  in.  Wort,  in  j 
Storage.  The  transaction 1 s card  type  is  checked,  and  a branch  is 
made  to  the  appropriate  edit  routine. 

If  the  card  type  is  'F1‘,  the  processing  is  as  follows:  An  accumu- 

lator for  'FI'  transactions  read  is  incremented.  If  the  level  identi- 
fication on  the  card  is  missing,  an  error  message  is  stored  in  a 
table.  A routine  is  performed  to  edit  the  ship  identifier  on  the 
card.  If  the  UIC  field  is  not  numeric  an  error  message  is  stored . 

If  the  UIC  field  is  present  a routine  is  performed  to  find  the 
UIC  .in  the  SHIP  file  on  the  database.  If  the  UIC  is  not  found, 
an  error  message  will  be  stored.  If  the  card  function  is  'D'  and 
no  errors  have  occurred  thus  far,  a branch  is  made  to  a delete  rou- 
tine. If  the  card  function  is  'D'  and  errors  have  been  found,  there 
is  a branch  to  an  end  of  transaction  routine.  If  the  card  function 
is  not  'D',  editing  continues.  If  the  level  name  is  missing,  ar 
error  message  is  stored.  If  the  update  date  is  missing,  or  is  not 
numeric,  an  error  message  is  stored.  A routine  that  edits  card 
function  for  'A',  'C',  or  ' D ' is  performed  and  if  the  function  is 

not  valid,  an  error  message  will  be  stored.  At  this  point,  if  any 
errors  have  occurred,  there  is  a branch  to  an  end  of  transaction 
routine.  If  no  errors  have  occurred  and  card  function  is  'C', 
there  is  a branch  to  a change  routine.  Otherwise  the  program  falls 
into  the  add  routine  for  a LEVEL  record. 

The  SHIP  owner  of  the  SHIP-LEVEL  set  is  found.  Card  data  is  moved 
into  the  appropriate  LEVEL  record  fields  and  the  new  record  is 
stored.  If  the  error  status  indicates  that  an  identical  record 
already  exists,  an  error  message  is  stored  and  there  is  a branch 
to  an  end  of  transaction  routine.  If  the  record  is  added  success- 
fully, an  accumulator  for  LEVEL  records  added  is  incremented,  the 
record  and  its  database  key  are  displayed,  and  there  is  a branch 
back  to  the  road  paragraph. 

The  Change  routine  is  as  follows:  The  LEVEL  record  to  be  changed 

is  obtained.  If  the  record  is  found,  card  data  is  moved  into  the 
LEVEL  record  fields  and  the  record  is  modified.  If  it  is  modified 
successfully,  an  accumulator  for  LEVEL  records  changed  is  incre- 
mented, the  record  and  its  database  key  are  displayed,  and  there  is 
a branch  back  to  the  read  paragraph. 

The  routine  to  delete  a LEVEL  record  is  as  follows:  Tho  ship  and 

level  are  used  to  obtain  the  record  to  be  deleted.  If  the  record 
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is  deleted.  I i the  delete  is  successful,  . m accumulator  J cj j LEVEL 
records  deleted  is  incremented  and  there  is  a branch  back  to  the  read 
paragraph . 

The  end  of  transaction  paragraph  for  a LEVEL  record  adds  to  an 
accumulator  for  'FI'  cards  with  errors,  performs  a routine  to  print 
error  messages,  and  branches  back  to  the  read  paragraph. 

If  the  card  type  is  'Gl'  or  'Hi',  the  processing  is  as  follows:  hn 

accumulator  for  'Gl'  and  ' HI 1 transactions  read  is  incremented.  If 
the  card  type  is  'III*  the  class  on  the  card  is  moved  to  a hold  area 
and  there  is  a routine  performed  to  edit  class.  If  the  card  typo  is 
'Gl1,  the  ship  code  on  the  card  is  moved  to  a hold  area  and  there  is 

a routine  performed  to  edit  UIC  . If  the  class  is  found  to  be 

numeric  on  the  'lil'  transaction,  a routine  to  find  the  class  in  the 
CL/\SS  file  is  performed.  If  the  UIC  on  the  'Gl'  transaction  is 
present,  a routine  to  find  the  ulC  in  the  SHIP  file  is  performed. 

The  watchstation  is  moved  to  a hold  area  and  an  edit  routine  is 
performed.  If  the  watchstation  is  numeric  a routine  to  find  it  in 
the  KS TITLE  file  i.  performed.  7it  this  point  the  editing  is 
finished  if  the  card  function  is  'D' , and  one  of  the  following  occurs: 
If  no  card  errors  were  found,  there  is  a branch  to  the  delete  V.'S 
routine;  if  card  errors  wore  found,  there  is  a branch  to  an  end  of 
transaction  routine.  If  the  function  is  not  'D',  editing  continues. 

If  the  WSMANNING  field  is  not  equal  to  either  'L',  'M',  'X',  'C',  or 

space  an  error  message  is  stored.  There  is  a loop  to  edit  the 

conditions:  A condition  counter  is  incremented  by  1.  If  it  exceeds 

7,  there  is  a branch  out  of  the  loop.  If  the  condition  is  spaces, 
spaces  are  moved  to  a hold  area  and  there  is  a branch  to  the  begin- 
ning of  the  loop.  If  tile  condition  is  not  spaces,  but  the  held  area 
for  conditions  is  (indicating  a ■ p’-.ior  condition  with  spaces),  n 
error  message  is  stored  and  there  is  a branch  out  of  the  loop.  The 
condition  is  looked  up  in  the  CONDTITLE  file.  It  is  not  found,  an 
error  message  is  stored.  There  is  a branch  to  the  beginning  of  the 
loop,  Once  out  of  the  loop,  the  condition  counter  is  reset  to  xero 
and  the  condition  ho]d  area  is  reset  to  '99'.  Next  the  OEC  is  checked 
for  ' E'  or  'O'  and  branches  are  made  to  the  respective  edit  routines 
for  either  enlisted  or  officer.  If  the  OEC  in  neither  of  the  above, 
an  error  message  is  stored.  If  the  enlisted  Rating  Designation  and 
Associated  Rating  fields  are  both  non-blank,  an  error  message  is 
stored.  The  enlisted  edit  converts  an  enlisted  paygrnde  of  'AR', 

'SR',  or  'FR'  to  'AR';  ' AA ' , ' SA ' , 'FA'  to  ' AA ' ; 'AN',  'SN'  or  ' FN ' 
to  ' N'.  There  is  then  a loop  to  convert  the  enlisted  paygrades  to 
numeric  codes:  An -enlisted  counter  is  incremented  by  1.  If  the 

counter  exceeds  9 (only  9 valid  values),  an  error  message  is  stored 
and  there  is  a branch  out  of  the  loop.  The  pay  grade  from  the  card 
is  compared  to  the  pay  grade  in  the  table  (ENLISTED-CONVERSION-TABLE). 
If  the  two  are  equal,  the  paygrade  is  overlayed  with  the  current 
value  of  the  enlisted  counter  and  there  is  a branch  out  of  the  loop. 

If  the  two  are  not  equal,  there  is  a branch  to  the  beginning  of  the 
loop.  Once  out  of  the  loop,  the  enlisted  counter  is  reset  to  zero 
and  there  is  a branch  to  the  next  edit  routine.  The  first  edit  for 
officers  is  rating  designation.  Valid  values  arc  spaces,  'OFF',  or 
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mir.  1 i c*a . I f l- he  rati  ng  closinnut  ion  in  oi  her  than  those,  an  > ror 
me  sir.. -go  is  stored.  If  the  offices  Rating  Designation  and  A.-.:  .•  vial  oil 
Rating  fields  are' both  non-blank,  an  error  message  .is  stored.  There 
is;  a loop  to  convert  the  pay  grade  to  numerics:  An  officer  counter  i 

incremented  by  1.  If  it  exceed::  1-1  (only  11  valid  value.;/  , an 
error  message  is  stor’d  and  there  is  a branch  out  of  the  loop.  The 
pay  grade  on  the  card  is  compared  to  one  in  the  table  (W-OI'FICLR- 
CONVERSION-TALLE)  . If  the  two  are  equal,  the  pay  grade  on  the:  card  is 
overlayed  by  the  offices  count oi  and  there  is  a branch  out  of  the  loo 
If  the  two  are  not  equal,  there  is  a branch  back  to  the  bocii.  ring  of 
the  loop.  Once  out  o;  the  loop,  the  officer  counter  is  resi  to 
zero.  The  field  holdi  the  number  of  watchstandcrs  is  edited  next. 
If  the  field  contains  spaces,  it  is  converted  t:o  '01'.  If  th  field 
does  not  hold  a valu°  in  the  range  '01'  - '09',  an  error  mos:  ige  is 
stored.  If  the  OMWPERV.’CEK  field  is  not  numeric,  an  error  message  is 
stored.  If  one  of  either  the  Scarchkey  or  the  organizational  code  is 
not  present,  an  error  message  is  stored.  If  the  Searchkey  is  present 
and  is  not  numeric,  an  error  message  is  stored.  Next,  a routine 
is  performed  that  edits  the  card  function,  arid  the  editing  is  com- 
plete. If  any  card  errors  were  found,  there  is  a branch  to  an  end 
of  transaction  routine.  If  there  were  no  errors,  there  is  a brancu 
to  a change  routine.  If  function  is  'C',  or  the  program  drops  into 
an  add  routine. 

For  card  types  ' Gl'  and  '111'  with  function  'A'  the  processing  is 
as  follows.:  If  card  type,  is  'Gl'  the  UIC  on  the  card  is  used  to 

obtain  the  SHIP  record  owner  of  the  SHIP-WS  set  to  which  the  new 
WS  is  to  belong.  If  the  card  type  is  'HI'  the  class  on  the  card 
is  used  to  obtain  the  CLASS  owner  record  of  the  CLASS-V.’S  sot  to 
which  the  new  WS  is  to  belong.  The  data  from  the  card  is  moved 
into  the  appropriate  WS  record  fields  in  Working  Storage  and  the 
record  is  stored.  If  it  is  stored  successfully  it  is  connected 
to  either  a CLASS-WS  set  or  a SHIP-WS  set  depending  on  the  card 
type  being  'HI'  or  'Gl',  respectively.  If  the  WS  is  connected,  to 
a set  successfully,  an  accumulator  for  WS  records  added  is  in- 
cremented, the  database  key  is  displayed,  and  there  is  a branch 
back  to  the  read  routine. 

To  change  a WS  record  the  processing  is  as  follows:  If  the  key 

field  on  the  card  equals  a hold  area  for  that  field  and  the  card 
types  are  equal  (indicating  a duplicate  WS  record  has  already  been 
changed),  there  is  a branch  to  the  'Add  WS ' routine.  If  the  card 
type  is  'Gl'  the  UIC  field  is  used  to  obtain  the  SHIP  record 
that  is  owner  of  the  set  to  which  the  WS  to  be  changed  belongs, 
otherwise  the  class  field  is  used  to  obtain  the  respective  CLASS 
owner.  The  counter  for  errors  is  stored  and  the  watchstation  on 
the  card  is  moved  into  a hold  area.  Then  if  the  card  typo  is  'Gl' 
a routine  is  performed  to  locate  the  WS  record  to  be  changed  v.i  a 
the  SJilP-WS  set  otherwise  a routine  is  performed  to  locate  the  WS 
record  via  the  CLASS-WS  set.  After  this  routine  is  performed,  if 
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If  tho  WS  record  is  located,  its  database  };cy  is  stored.  Th-n 
there  is  a routine  periormod  to  locate  and  process  duplicate  WS 
records.  If  a duplicate  record  is  found  and  modified,  n routine 
is  performed  to  delete  tho  first  VIS  record  obtained  and  Ur.  . is 
a branch  out  of  the  change  routine.  If  duplicates  are  : ..... 

the  first  WS  record  is  re-obtnin  d by  using  its  database  k>  v,  card 
data  is  moved  into  the  appropriate  WS  record  fields  in  Work  j nq  Storage 
and  the  record  is  modified.  If  tho  operation  in  successful,  an  ac- 
cumulator for  WS  records  changed  is  incremented,  the  record  modified 
is  displayed  along  with  its  database  key,  and  the  W5KEY  is  stored. 

Once  out  of  the  change  routine,  the  area  lo  indicate  duplic  . :.os 
changed  is  cleared,  tho  duplicate  counter  is  reset  to  zero  and 
then  is  a branch  back  to  the  read  paragraph. 

To  delete  a WS  record  the  following  occurs:  If  the  card  typo  is 

'Gl 1 the  SHIP  owner  of  the  WS  record  is  obtained,  otherwise  the 
CLASS  owner  of  the  WS  record  is  obtained.  The  card  error  counter 
is  stored  and  the  watchstation  is  moved  to  a hold  area.  If  the 
card  type  is  1 G1 ' a routine  is  performed  to  locate  the  WS  record 
to  be  deleted  via  the  S11IP-WS  set;  otherwise,  a routine  is  per- 
formed to  locate  the  record  via  the  CLASS-WS  set.  If  an  erro  occurs, 
there  is  a branch  to  an  end  of  transaction  routine.  If  the  record 
is  found,  its  database  key  is  stored.  Then  there  is  a routine  per- 
formed to  locate  and  process  any  duplicate  WS  records.  The  WS  re- 
ord  whose  key  was  stored  is  re-obtained  and  deleted.  If  the  delete 
is  successful,  the  counter  for  duplicates  is  set  back  to  zero,  an 
accumulator*  for  WS  records  deleted  is  incremented,  and  there  is  a 
branch  back  to  the  read  paragraph. 

The  end  of  transaction  routine  for  card  types  ' Gl'  and  'Ml'  add 
to  an  accumulator  for  'Gl'  and  'HI'  cards  with  errors,  performs  a 
routine  to  print  error  messages,  and  branches  back  to  the  read 
paragraph . 

The  processing  for  card  types  'G5'  and  ' II 5 ' is  as  follows:  An 

accumulator  for  'G5'  and  '115'  cards  read  is  incremented.  If  the 
card  type  is  '115'  the  class  is  moved  to  a hold  area  and  a routine 
is  performed  to  edit  it,  otherwise  the  UIC  is  moved  to  a hold  area 
and  there  is  a routine  performed  to  edit  it.  If  the  field  holding 
class  is  numeric;  if  card  type  is  ' II 5 ' a routine  is  performed  to 
find  the  class  in  the  CLASS  file.  The  watchstation  is  moved  to  a 
hold  area  and  there  is  a routine  performed  to  edit  it.  If  it  is 
numeric,  a performed  routine  looks  it  up  in  the  WSTITL13  file.  The 
individual  ROCs  to  be  added  or  deleted  are  edited  in  a loo;).  There 
arc  three  groups  of  four  ROCs  each  and  the  loop  proceeds  as  follows: 

A counter  for  'group'  is  incremented  by  1.  If  i.t  exceeds  3,  there 
is  a branch  out  of  the  loop.  A counter  for  ROCs  within  a group  is 
incremented  by  1.  If  it  exceeds  4,  it  is  re-initialized  to  zero 
and  there  is  a branch  to  tho  beginning  of  the  loop.  If  the  ROC 
is  spaces,  spaces  are  moved  to  a hold  area  and  there  is  a branch 
to  the  paragraph  that  edits  one  group.  If  the  ROC  is  not  spaces, 
but  the  hold  area  is,  an  error  message  is  stored  and  there  is  a 
branch  out  of  the  loop.  If  the  ROC  is  not  numeric,  an  error  message 
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of  the  g roup  edit.  Once  out  of  the  loop,  the  counters  for  gr,  •.  s 
and  ROCs  within  a group  are  sot  to  zero,  and  the  hold  area  is  given 
the  value  ’0999'.  A routine  to  edit  card  function  is  peri  orm,  a . A 
second  edit  on  function  stores  an  error  message  if  card  fra  •:  j*  a is 
'C'.  At  this  point,  editing  is  complete . If  errors  occurred  there 
is  either  a branch  to  the  delete  WSROCs  because  function  is  'u',  or 
the  program  drops  into  the  add  WSROC  routine. 

To  add  a WSROC (s)  the  following  tabes  place:  If  the  card  t. '/pc  is 

'GO1  the  me  is  used  to  obtain  the  SHIP  owner  of  the  f.’S  i <.  which 
the  WSROCs  are  to  be  added;  otiierwi.se  the  clans  is  us*,  i to  obtain 
the  CLASS  owner  of  the  WS  to  which  the  WSROCs  are  to  be  audod.  The 
error  counter  is  sto  ed  and  the  watchstation  is  moved  to  a hold  area. 
Then  if  the  card  type  is  ' G5',  the  WS  owner  of  the  WS-WSROC  set  to 
which  the  WSROCs  are  to  be  added  is  located  via  the  SillP-WS  set; 
otherwise  it  is  located  via  the  CLASS-WS  set.  If  an  error  occurs, 
there  is  a branch  to  an  end  of  transaction  routine.  If  the  WS 
record  is  found,  its  database  key  is  stored.  A routine  is  performed 
that  locates  duplicate  WS  records.  If  no  duplicates  are  found,  the 
WS  record  whose  database  key  is  in  hold  is  re-obtained  and  there  is 
a branch  to  the  paragraph  that  stores  the  new  VJSROCs. 

If  there  is  a duplicate,  its  WS-WSROC  set  is  checked  to  see  if '.it 
is  empty.  If  it  is,  the  duplicate  counter  is  reset  to  zero  and 
there  is  a branch  back  to  find  another  duplicate.  If  the  sot  is 
not  empty,  the  VJSROCs  will  be  added  to  this  set.  There  is  a loop 
used  to  actually  add  the  WSROCs  that  uses  two  subscripts  because  of 
the  way  the  ROCs  are  set  up  on  the  transaction.  The  loop  processing 
is  as  follows:  The  first  subscript  is  incremented  by  1.  If  it  is 

greater  than  3,  there  is  a branch  out  of  the  loop.  The  second 
subscript  is  incremented  by  1.  If  it  exceeds  4,  it  is  r^set  to 
zero  and  there  is  a branch  back  to  the  beginning  of  the  loop.  If 
the  field  is  spaces,  there  is  a branch  out  of  the  loop;  otherwise 
the  ROC  is  moved  into  the  appropriate  WSROC  field  in  Working  Stor- 
age and  is  stored.  If  the  error  status  indicates  a duplicate,  an 
error  message  is  stored,  and  there  is  a branch  back  to  the  second 
paragraph  in  the  loop.  If  the  add  is  successful,  an  accumulator  for 
WSROCs  added  is  incremented,  tlic  WSROC  and  its  database  key  are 
displayed  and  there  is  a branch  back  to  the  beginning  of  the  loop. 
Once  out  of  the  loop,  both  subscripts  and  the  duplicate  counter 
are  set  to  zero.  If  any  erros  occurred,  a routine  is  performed  to 
print  error  messages.  An  accumulator  for  'G5'  and  'il5'  add  trans- 
actions is  incremented,  and  there  is  a branch  back  to  the  read  para- 
graph. ! 

The  processing  for  deleting  WSROCs  is  as  follows:  The  logic  is  the 

same  as  for  adding  WSROCs  until  the  point  of  handling  WS  duplicates. 

A routine  is  performed  to  find  a duplicate.  If  a duplicate  is  not 
found,  the  WS  whose  database  key  is  stored  is  rc-obtained  and  there 
is  a branch  out  of  the  paragraph  that  handles  duplicates.  If  a 
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duplicate  is  found  and  its  V.'d- V.'SkOC  set  is  non-empty,  the  du;  J.ic.Ui.* 
counter  is  reset  to  zero  and  there  is  a branch  back  to  the  b , inning 
of  the  routine  to  handle  duplicates.  If  no  duplicates  are  ‘ous:, 
the  original  V.’S  record's  WS-V.'SKOC  set  is  checked . If  .if  is  e.  pty 
(no  VIS  ROCs  to  delete),  an  error  message  is  stored  and  there  is  a 
branch  to  an  end  of  transaction  routine.  The  routine  that  deletes 
the  V.'SROCs  loops  through  the  ROCs  on  the  transactions  that  are 
divided  into  three  groups  with  4 ROCs  per  group:  The  group  sub- 

script -is  incremented  by  one.  l'f  it  exceeds  three  there  is 
branch  to  got  out  of  the  loop.  The  second  subscript  is  inej.  omented 
by  one.  if  it  is  greater  than  4,  it  is  eset  to  zero  and  the -0  is 
a branch  to  the  beginning  of  the  loop.  If  the  ROC  field  is  blank, 
there  is  a branch  to  get  out  of  the  loop.  Otherwise  the;  ROC  is 
used  to  obtain  the  WSROC . If  it  is  not  found  an  error  message  is 
stored  and  there  is  a branch  to  the  second  paragraph  of  the  loop. 

If  it  is  found,  it  is  deleted.  If  the  delete  is  successful,  an 
accumulator  for  WSROCs  deleted  is  incremented  and  there  is  a brand) 
to  the  second  paragraph  of  the  loop.  Once  out  of  the  loop,  both 
subscripts  and  the  duplicate  counter  are  set  to  zero.  If  errors 
occurred,  there  is  a routine  performed  to  print  error  messages.  An 
accumulator  for  1 G 5 ' and  M3 5 ’ delete  transactions  recid  is  incremented 
and  there  is  a branch  to  the  read  paragraph.  The  end  of  transaction 
routine  adds  to  an  accumulator  for  'G5'  and  ' H 5 1 cards  with  errors, 
a routine  to  print  error  messages  is  performed,  and  there  is  a 
branch  back  to  the  read  paragraph. 


If  the  card  type  is  * Jl',  the  processing  is  as  follows:  An  accumula- 

tor for  Jl  transactions  read  is  incremented.  The  ,UIC  is  moved  to 
a hold  area  and  a routine  to  edit  it  is  performed.  If  the  UIC  is 
present,  a routine  to  locate  it. in  the  SHIP  file  is  performed.  If 
the  level  is  blank,  an  error  message  is  stored.  A routine  to  edit 
function  is  performed.  Then,  if  the  function  is  'C'  an  error  mes- 
sage* is  stored.  There  are  three  groups  of  ROCs  on  the  transaction 
with  four  ROCs  in  each  group.  They  are  edited  in  a loop:  The  group 

subscript  is  incremented.  If  it  exceeds  3 there  is  a branch  to  get 
out  of  the  loop.  The  ROC  subscript  is  incremented.  If  it  exceeds 
4,  it  is  reset  to  zero  and  there  is  a branch  to  the  beginning  of  the 
loop.  If  the  ROC  is  blank,  spaces  are  moved  to  a hold  area  and 
there  is  a branch  back  to  the  second  paragraph  of  the  loop.  If  the 
ROC  is  not  spaces  and  the  hold  area  is,  an  error  message  is  stored. 

If  the  ROC  is  not  numeric,  an  error  message  is  stored  and  there  is 
a branch  back  to  the  second  paragraph  of  the  loop.  If  the  ROC  is 
numeric,  a routine  is  performed  to  look  it  up  in  the  ROCTITLC  file. 
Then  there  is  a br cinch  bade  to  the  second  paragraph  of  the  loop. 

Once  out  of  the  xoop,  the  two  subscripts  are  sot  to  zero  and  the  ROC 
hold  area  is  set  to  '9999'.  At  this  point,  the  'Jl'  editing  is 
complete.  If  card  errors  were  found,  there  is  a branch  to  an  end  of 
transaction  routine.  If  errors  arc  found  there  is  a branch  to  the 
end  of  transaction  routine.  If  no  errors  are  found  and  card  func- 
tion is  '[)'  there  is  a branch  to  the  delete  ROC  routine,  otherwise 
the  program  drops  into  the  add  ROC  routine. 
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To  iuM  a HOC  l ho  processing  is  as  follows:  The  UIC  and  level  are 

used  to  locate  the  LEVEL  record  owner  of:  the  LEVEL- ROC  set  t.o  which 
the  ROCs  are  to  bo  added.  If  it  is  not  found,  an  o tor  Message  is 
stored  and  there  is  a branch  to  an  end  of  transaction  routine.  The 
ROCs  .ire  added  by  a loop  routine:  A group  subscript  is  incremented. 

Tf  it  exceeds  3,  there  is  a branch  to  got  out  of  the  loop.  A 
second  subscript  for  ROCs  within  a group  is  incremented.  1!  it.  is 
greater  than  4,  it  is  reset  to  zero  and  there  is  a branch  t:o  the 
beginning  of  the  loop.  If  the  ROC  field  in  blank,  there  is  a 
branch  to  got  out  of  the  loop.  The  ROCTITLE  record  owner  of  the 
ROCTITLE-ROC  set  to  which  the  ROC  will  belong  is  obtained.  The 
ROC  is  moved  to  the  appropriate  ROC  field  in  working  storage  and 
is  stored.  If  the  error  status  indicates  a duplicate,  an  error 
message  is  stored  and  there  is  a branch  to  the  second  paragraph  of 
the  loop.  If  the  operation  is  successful,  an  accumulator  for  ROC 
records  added  is  incremented,  the  record  and  its  database  key  are 
displayed  and  there  is  a branch  to  the  second  paragraph  of  the  loop. 

Once  out  of  the  loop,  he  two  subscripts  are  set  to  zero.  If  an 
error  occurred  a routine  to  print  error  mess^^ges  is  performed.  An 
accumulator  for  'Jl'  add  transactions  is  incremented  and  there  is 
a branch  back  to  the  read  paragraph. 

The  ROC  delete  routine  is  as  follows:  The  UIC  and  level  eiro  used 

to  locate  the  LEVEL  record  owner  of  the  LEVEL-ROC  set  from  'which 
the  ROCs  arc  to  be  deleted.  If  it  is  not  found,  an  error  message 
is  stored  and  there  is  a branch  to  an  end  of  transaction  routine. 

If  the  LEVEL -ROC  set  from  which  the  ROCs  are  to  be  deleted  is 
empty,  an  error  message  is  stored  and  there  is  a branch  ’to  an  end 
of  transaction  routine.  The  ROCs  are  deleted  in  a loop  routine: 

A group  subscript  is  incremented.  If  it  exceeds  3,  there  is  a 
branch  out  of  the  loop.  A second  subscript  for  ROCs  within  a group 
(on  the  card)  is  incremented.  If  it  exceeds  4,  it  is  reset  to  j 

zero  and  there  is  a branch  to  the  beginning  of  the  loop.  If  the 
ROC  field  is  blank,  there  is  a branch  to  get  out  of  the  loop.  rhe 
ROC  record  to  be  deleted  is  obtained  using  the  ROC  on  the  card.  If 
it  is  not  found,  an  error  message  is  stored  and  there  is  a branch 
back  to  get  another  record.  If  it  is  found,  it  is  erased,  an  ac- 
cumulator for  WSROC  records  deleted  is  incremented,  and  there  is  a 
branch  to  get  another  record. 

Once  out  of  the  loop,  the  subscripts  are  set  to  zero.  If  any  errors 
occurred,  a routine  to  print  error  messages  is  performed.  An 

accumulator  for  Jl  delete  transactions  is  incremented  and  there  is  | 

a branch  back  to  the  read  paragraph. 

The  end  of  transaction  routine  adds  to  an  accumulator  for  Jl  trans- 
actions with  errors,  performs  a routine  to  print  error  messages, 
and  branches  back  to  the  read  paragraph. 

The  following  paragraphs  describe  routines  that  are  performed  at 
various  times  during  program  processing.  The  routines'  functions 
will  be  identified  and  the  logic  will  be  explained.  The  paragraphs 
will  be  referenced  by  their  numeric  portions  only. 
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■ . . Prior  t<  V h i : rout ino , a cord  h. is  boon 

obtair  d . Tl  logic  follows:  A duplicate  ; 1 

obtained.  if  the  error  status  indicates  that  there  is  no 
duplicate,  t.ln  r0  is  a branch  to  get:  out  of  the  rout  ino.  If 
the  cars  bcin  j processed  is  an  'III  ' or  an  'IlG'  a routine  is 
performed  to  d -I  ermine  if:  the  WS  is  a me:  !>:i  of  a C1.ASS-1VS 
s('t ; otherwise;  .1  routine  is  performed  to  determine  it.  I lie  lv-.' 
is  a 1 mber  o 1 SHIP  VIS  set.  If  the  error  status  indicate 
no  ■ t membership  in  cither  cave,  there  is  a branch  to  the 
bog ‘ 1 'inn  of  1 he  rout i no.  Othm  vise,  a true  duplicate  has 
been  fruod  an!  it  is  i.uclc  to  be  the  current  record  of  run- 
unit.  A duplicate  counter  is  incremented.  If  the;  card  tyj 
is  1 G I ■ 1 or  ' It". there  is  a branch  to  got  out  of  the  routin'  . 
Therefore,  the  following  processes  are  performed  only  for 
'Gl*  and  'HI'  transactions.  If  the  V.G-WSROC  set  for  the 
duplicate  WS  is  empty  there  is  a branch  to  the  delete  portion 
of  the  routine.  Otherwise,  the  duplicate  VIS  is  made  to  be 
current  record  of  run  unit.  If  the  card  function  is  1 C*  and 
the  duplicate  changed  indicator  is  blank,  a routine  to  modi'/ 
the  VIS  record  is  performed,  the  duplicate  changed  indicator 
is  given  a value  of  ’YES'  and  there  is  a bru ich  back  to  the 
beginning  of  the  routine.  If  the  function  is  not  'C'  or  the 
duplicate  indicator  has  a value  other  than  spaces,  the  pro- 
cessing continues  with  a delete  routine.  The  duplicate  lv’S 
record  is  deleted,  a routine  is  performed  to  obtain  the  VIS 
whose  database  key  is  in  hold,  and  there  is  a branch  back  to 
the  beginning  of  the  routine. 

(2)  346  - 348  is  used  to  obtain  a WS  record  whose  database  key 
has  been  stored  and  then  delete  that  record. 

(3)  350  edits  UIC  : If  the  ship  is  not  present  on  the  card  and  in  the 

SHIP  file,  an  error  message  is  stored. 

(4)  355  - 356  is  a SHIP  record  look-up:  Given  a UIC  value  the  routine 
tries  to  obtain  a SHIP  in  the  SHIP  file.  If  one  is  not  found, 

an  error  message  is  stored. 

(5)  360  edits  class:  If  the  class  value  is  not  numeric,  an 

error  message  is  stored. 

(G)  365  - 366  is  a CLASS  record  look-up:  Given  a class  value  the 

routine  attempts  to  obtain  a CLASS  record.  If  one  is  not 
found,  an  error  message  is  stored. 

(7)  370  edits  card  function.  If  the  function  is  neither  'A'  nor 

'B'  nor  'C',  an  error  message  is  stored. 

(0)  300  edits  watchstation : If  the  watchstation  number  is  not 

numeric,  an  error  message  is  stored. 
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found,  an  01. ror  message  is  stored. 


(10)  4 00  - 405  is  a ROCTIT.LE  look-up.  Given  a ROC  value,  the 
rout:  i no  attempts  to  find  a ROCTITLE  record.  1 ) on--  is  net 
found,  an  error  message  is  stored. 

(11)  407  locates  a WS  record  via  the  S1IIP-WS  set:  The  routine' 

obtains  the  next  V.’S  record  of  the  SHIP-WS  set.  If  there  are 
no  more  (error  status  = '0307')  an  error  message  is  stored 
and  there  is  a branch  to  an  exit  paragraph.  If  the  WS  rente  d 
found  lias  the  watchstat  ion  that  is  on  the  transaction  being 
processed,  there  is  a branch  to  an  exit  paragraph,  otherwise 
there  is  a branch  to  the  beginning  of  the  routine. 

(12)  408  locates  a WS  record  via  the  CLASS-WS  set:  The  routine  obtains 
the  next  US  record  of  the  CLASS-WS  set.  If  there  are  no  more,  an 
error  message  is  stored  and  there  is  a branch  to  an  exit  paragraph 
If  the  correct  WS  is  found,  there  is  a branch  to  an  exit  paragraph 
otherwise  there  is  a branch  to  the  beginning  of  the  loop. 

(13)  415  is  an  error  routine:  It  is  performed  when  an  error  status 

indicates  a problem.  The  error  status  and  card  being  processed 
are  displayed  along  with  an  indicator  to  identify  the  paragraph 
where  the  problem  occurred.  Then  there  is  a branch  to  the 
paragraph  that  prints  edit  totals. 

(14)  420  - 435  print  error  messages  stored  when  a transaction  is 
being  edited.  The  logic  is  as  follows: 

(15)  If  the  line  count  exceeds  43,  a routine  to  begin  a new  page 
is  performed.  The  input  transaction'  is  moved  to  the  print 
line  and  is  printed.  The  card  is  underlined  and  another  line 
is  printed  with  spaces.  The  line  count  is  incremented. 

There  is  a loop  to  print  the  error  messages:  A subscript 

(W-ERR-IND)  is  incremented  by  one.  If  the  subscript  is  greater 
than  the  number  of  errors  that  occurred  (w-CRD-ERRS) , the  loop 
is  ended.  There  is  a routine  performed  to  determine  whether 

to  go  to  a new  page  and  print  headings,  if  necessary.  An  error- 
message  is  moved  from  a table  (W-PRT-ERR)  to  the  print  line 
and  is  printed.  The  line  count  is  incremented.  Then  there  is 
a branch  to  the  beginning  of  the  loop  which  continues  until 
all  error  messages  are  printed.  Once  out  of  the  loop,  an 
accumulator  for  card  type  errors  is  incremented,  two  lines  of 
spaces  are  printed,  the  table  that  held  the  error  and  the 

. arcci  that  hold  the  card  in  error  are  cleared,  and  the  subscript 
and  the  error  counter  arc  rc-i  initialized  to  zero . 

(16)  435  is  the  routine  to  prir.t  report  headers:  The  header  routine 

sots  the  line  count  back  to  zero  and  adds  1 to  the  page  counter. 

It  then  prints  heading  on  a new  page  by  moving  to  the  print 
line  headers  that  are  set  up  in  working  storage  and  printing 
them  one  by  one. 
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(IV)  ‘140  determines  v/hen  to  go  to  a new  paye:  The  line  oho  i. 

routine  checks  to  see  if  the  line  count  is  greater  than  AO, 
and  if  it  is,  the  header  routine  is  performed. 

(18)  44  5 prints  a line  then  rc— initializes  the  print  line  to 
spaces. 

(19)  450  - 4G5  print  edit  totals.  The  routine  loops  through  a 
table  where  the  totals  arc;  stored  (W-CARD-EDT-TAELE) . Ref<  ra- 
the loop  begins,  headers  are  printed  on  a new  page,  and 
counters  for  ROCs  and  WSRQCs  added  and  deleted  are  leaded 
into  the  table.  The  loop  processing  is  as  follows.  A sub- 
script (W-TYPE-JND)  to  identify  the  transaction  or  record 
type  is  incremented.  If  the  subscript  is  greater  than  G 
(six  groups  of  totals),  the  subscript  j.s  re-initialized  to 
zero  and  there  is  a branch  to  an  end  of  program  routine. 

Another  subscript  (W-CTR-IND)  is  incremented  (for  the  totals). 
If  the  subscript  is  greater  than  5,  it  is  re-initialized  to 
zero  and  there  is  a branch  to  print  the  line.  The  data  from 
the  table  is  moved  to  the  print  line  and  printed.  Then  there 
is  a branch  to  the  beginning  of  the  loop.  The  loop  continues 
until  all  the  edit  totals  are  printed. 

The  last  paragraph  of  the  program  closes  all  files  and  database  area 
and  ends  program  processing. 
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Module  Description.  The  VJatch  Station  Generation  Module, 
NMWF01 , determines  a minimum  list  of  watchstetions  and  walch- 
stnnders,  by  condition,  for  a specified  ship  and  tasking  level. 
The  program  was  written  under  contract  number  N-00014-76-C-P-173, 
effective  2 4 November  1975. 

Module  Functions.  The  following  functions  are  performed  by 
NKV.TOl: 

For  a given  ship  and  tasking  level,  as  specified  by  an 

NMRS  Load  or  Produce  command 

(1)  Compute  the  minimum  list  of  watchstations  and 
watchstanders  needed  to  satisfy  the  ship's  Re- 
quired Operational  Capabilities  Statement  (ROC) , 
and 

(2)  output  that  list  as  one  watchstation  record  per 
watchstation,  per  watchstander , showing  up  to  eight 
ship  conditions  with  the  respective  watchstander 
requirements  for  each. 


Accuracy  and  Validity.  The  Ship  ROC/Watchstation  Database 
is  edited  and  validated  in  a series  of  other  modules.  The  input 
stream  (carl  images)  is  read  to  find  NMRS  Load  (LOD)  and  Produce 
(PRD)  Commands,  which  are  further  edited.  For  both  card  types, 
the  following  edits  take  place: 

a.  SEQNO  (Columns  2-3)  must  equal  '01', 

b.  TRANSCODE  (Columns  6-8)  must  equal  'CMD.' , 

c.  UIC  (Columns  12-16)  must  be  found  as  the  CALC  key  of  a 
SHIP  record  on  the  database,  and  as  the  UIC  part  of 
the  CALC  key  of  a LEVEL  record,  and 

d.  TASKINGLEVEL  (Columns  17-28)  must  be  found  as  the 
LEVELID  part  of  the  CALC  key  of  a LEVEL  record. 

For  the  Load  command,  the  following  additional  edit  takes 
place: 

COMMAND  (Columns  9-11)  must  equal  'LOD', 


For  the  Produce  command,  the  following  additional  edit 
takes  place: 

a.  COMMAND  (Columns  9-11)  must  equal  'PRD',  and 

b.  RUNINDICATOR  (Columns  29-30)  must  equal  spaces. 
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Any  input  transaction  card  images  which  fail  to  meet  any 
of  these  edit  criteria  bypass  further  processing.  Only  those 
transactions  which  satisfy  all  the  above  edits  are  mud  to  . : 
duce  a list  of  watchs tat ions . 


Inputs . Inputs  to  NMWF01  may  be  either  or  both  of  two  dif- 
ferent types  of  input  transactions,  plus  six  different  Ship  HOC/ 
Watchstation  Database  record  types.  The  acceptable  input  trans- 
action types  are: 

a.  NMRS  Load  Command,  and 

b.  NMRS  Produce  Command. 

The  database  record  types  used  by  NMWF01  are: 

a. 

b. 

c. 

d . 

e. 

f . 


Outputs.  Output  from  NK.WF01  is  the  Watchstation  List, 
DAXMSSWS . 


CLASS 

LEVEL 

ROC 

SHIP 

WS 

WSROC 


Working 
areas  for  da 
tables  used 
totals;  and 


Storage.  Working  Storage  consists  of  various  hold 
ta  being  reformatted;  logical  variables  (switches) ; 
for  accumulating  totals;  accumulators  for  various 
subscripts  used  in  accessing  table  elements. 
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Chi  met  ori  st  i cr. . 

Input  Stiva:.i  Transactions . 

a . • TT-REC  ir.  the  card  input,  transaction. 

b.  Each  input  transaction  is  edited  according  to  specifica- 
tions for  the  particular  record  type  associated  with  the 
transaction.  These  requirements  are  stated  in  '2.2 
Module  Functions'.  If  the  record  contains  valid  data, 
the  transaction  is  used  to  generate  a WATCHSTATION  list 
for  the  SHIP/LEVELID;  otherwise  the  transaction  is  by- 
passed . 

c.  Valid  LOAD  or  PRODUCE  Commands  which  specify  a UIC  and/ 
or  LEVEL JD  not  matching  the  CALC  keys  for  the  SHIP  and 
LEVEL  records  cause  appropriate  diagnostic  messages  to  be 
displayed,  and  are  then  bypassed. 

d.  All  of  the  transaction  data  is  static. 

e.  The  input  transaction  file  is  a temporary  disk  file  that 
requires  one  IBM-3330  disk  track  per  156  input  records. 

Database  Records.  The  six  database  records  used  by  this 
program  are  maintained "by  other  programs  based  on  input  transac- 
tions subjected  to  a series  of  edits.  Data  edits  include  checks 
for  non-blank  data,  numeric  data,  table  lookups  (e.g. , MILTIPAY- 
GRADE,  OEC) , and  lookups  against  Database  records  considered  to 
comprise  a dictionary  of  valid  data  (e.g.,  UIC  on  the  SHIP  record, 
CLASS JD  on  the  CLASS  record,  etc.).  All  data  elements  affecting 
the  internal  operation  of  the-  Ship  ROC/Watchstation  Subsystem  are 
thoroughly  edited  to  prevent  errors. 

However,  a number  of  data  elements  which  are  merely  passed 
through  the  Subsystem  without  change  are  not  edited.  This  is 
because  the  edits  are  dependent  on  data  in  record  types  present 
on  the  NMRS  Database,  but  not  on  the  Ship  ROC/Watchstation  Data- 
base. Because  of  the  inherent  weakness  of  IDMS  in  not  allowing 
a program  to  access  more  than  one  database  at  a time,  it  is  not 
feasible  to  check  these  fileds  at  data  entry  time.  Besides,  as 
changes  arc  made  to  the  NMRS  Database,  it  would  be  virtually  im- 
possible to  revalidate  the  Ship  ROC/Watchstation  Database  accord- 
ingly. 

Therefore,  it  was  decided  that  since  all  WATC11STATI0N 
records  input  to  DIP  would  necessarily  be  edited  in  any  case  (due 
to  possible  analyst  input) , then  it  would  be  logical  to  not 
attempt  to  edit  them  against  an  out-of-date  copy  of  NMRS  data 
at  another  time.  Hence,  such  data  elements  as: 


a.  RATINCAbBR 

b.  WSNEC 

C.  DESIGCODE 

d.  PAYPLAN 

e . OCCUPATIOb’CODE 

f.  C I V P A Y G IIA  D E 

g . ORGCODE 

h.  RESERVECODE 

i . SEARCHORGKEY 

would  be  edited  only  by  numeric  checks  and  non-blank  checks,  as 
appropriate,  in  the  Ship  ROC/Watchstation  Subsystem.  Each  of 
these  data  elements,  as  well  as  the  others,  will  be  edited  by 

DIP. 


Further  problems  could  be  detected  by  DIP  in  its  edit,  es- 


pecially 

in  these  data 

a . 

UIC 

b. 

TASKINGLF.VEL 

c. 

VJSID 

d. 

CONDITION 

due  solely  to  changes  to  data  on  the  NMRS  Database  which  were 
not  entered  as  corresponding  changes  to  the  Ship  ROC/Watchstation 
Database.  These  would  be  errors  of  coordination,  and  not  errors 
due  either  to  the  Ship  ROC/Watchstation  Subsystem  or  to  DIP. 

The  only  viable  solution  to  such  possible  problems  is  to 
incorporate  the  Ship  ROC/Watchstation  Database  into  the  NMRS 
Database,  and  to  CALL  and/or  PERFORM  all  appropriate  edit  routines 
in  DIP  whenever  the  database  is  updated  or  WATCHSTATION  lists  arc 
generated.  This  has  already  been  discussed  with  the  Database 
Administrator  and  his  staff,  and  a number  of  steps  have  been 
taken  to  simplify  this  eventual  conversion: 

a.  ANS  COBOL/IDMS  has  been  used  as  the  source  programming 
language . 

b.  Data  clement  names  have  been  coordinated  (through  DETS) 
with  NMRS  names. 


c. 


Moduli;  documentation  to  NMRS  standards  has  boon  pro- 
vided for  all  Ship  ROC/Watchstation  modules. 

d.  NMRS  programming  conventions  have  been  observed. 

e.  A database  specification  has  been  written  according 
to  the  Database  /Administrator  1 s specifications  . 

Oil t put  - the  Watch s t a t ion  Pile. 

a.  Identification. 

(1)  The  DDNAME  is  DAXMSSWS . 

(2)  The  DSNAME  is  WEUIDAX.  MSS . SHIPROC . N . WS  . 

(3)  The  record  name  is I OM-WATCHSTATION . 

b.  The  Watchstation  File  is  output  to  be  the  primary  source 
for  WATCH  data  in  the  NMRS  Database. 

c.  The  Watchstation  File  contains,  for  each  specified  ship 
and  tasking  level,  a complete  list  of  all  watchstaticns 
required  to  be  manned  at  any  ship  condition  under  the 
applicable  Required  Operational  Capabilities  Statement 
(ROC).  Besides  identifying  the  ship,  tasking  level,  and 
watchstation,  the  record  contains  information  on  the 
.minimum  qualifications  for  the  watch stander , e.g.,  skill- 

class,  rating,  rate,  NEC,  organizational  component,  etc. 
for  each  ship  condition  at  which  the  watchstation  is 
manned . 

d.  All  of  the  watchstation  data  is  static. 

e.  The  Watchstation  File  is  a disk  file  that  requires  one 
IBM-3330  disk  track  per  52  Watchstation  records. 

Data  Environment. 

The  Ship  ROC  Table.  For  maximum  efficiency  of  both 
main  memory  einci  CPU  time,  the  Ship  ROC  table  was  developed  to 
store  the  ROC  data  for  the  selected  LEVEL.  The  table  make:; 
provision  for  ROC  elements  whose  SOCID  values  arc  in  the  range 
001  through  900.  Each  ROC  record  is  loaded  into  the  table  by 
moving  the  letter  'X'  (hexadecimal  E7)  to  W-SOC-MARK (SOCID) , 
where  SOCID  is  used  as  the  subscript  to  the  table.  The  Ship 
ROC  table  is  initialized  with  a period  (hexadecimal  4B)  in 
each  cell.  Bv  subscripting  the  table  with  SOCID,  random  rmcoss 
against  the  table  is  achieved,  rather  than  repeated,  laborious 
sequential  searches. 

The  Condition  Table.  The  condition  table  contains  an  entry 
(the  CONDITION  data  element)  for  each  condition  for  which 
watchstations  are  to  be  manned. 

Transaction  Statitistics . The  IJIC;  LEVELID,  and  count  of 
ROC  records  within  the  LEVEL-ROC  sot  arc  stored  for  up  to  100 
different  ships  and/or  ROCs. 
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Pro.n  • J^oyic.  The  Watchstation  Generation  program,  kMWFOl, 
is  written  in  a hierarchical  structure*  for  ease  of  programming, 
testing,  and  maintaining.  At  its  highest  level  .is  overall  program 
control.  This  includes  startup,  processing,  and  endup  routines. 
Included  as  startup  functions  are: 

o Binding  the  IDMS  run-unit  and  record  types, 


o Readying  the  IDMS  realms, 

o Opening  the  input  transaction  file  and  output  watch- 
station  file,  and 

© Initializing  certain  data  elements. 

Processing  encompasses  the  bulk  of  data  processing  in  this  program, 
and  will  be  discussed  at  length  in  subsequent  paragraphs.  Included 
as  endup  functions  are: 

o Finishing  the  IDMS  database,  and 

o Closing  the  input  transaction  file  and  output  watch- 
station  file. 

The  program  processing,  apart  from  startup  and  endup,  consists  of 
processing  transaction  control  cards,  and  processing  watchstation 
data  from  the  database.  Each  transaction  card  is  read,  and  edited 
to  determine  if  it  meets  the  criteria  detailed  in  Section  2.2.1 
of  this  Specification.  If  a transaction  card  does  not  meet  these 
criteria,  it  is  bypassed,  and  the  next  transaction  card  is  read, 
control  returns  to  the  topmost  hierarchical  routine,  program  con- 
trol, to  perform  the  endup  process. 

If  a transaction  card  does  meet  these  criteria,  then  the  "ready 
for  watchstation  generation"  flag  is  set.  But  before  a watch- 
station  list  for  the  specified  ship/tasking  level  is  produced,  a 
check  is  made  against  a table  of  previously  processed  ship/tasking 
levels  to  prevent  generating  a duplicate  list.  If  the  specified 
ship-tasking  level  has  already  been  processed  in  the  current  run 
of  the  program,  a message  is  displayed  describing  why  another 
watchstation  list  is  not  being  produced,  and  control  is  returned 
to  continue  reading  transaction  cards.  Otherwise,  processing  be- 
gins for  the  specified  ship/tasking  level,  as  detailed  in  the 
following  paragraphs. 

The  processing  of  a ship/tasking  level  is  divided  into  three 
routines: 


o Setup 

® Process  class  watchstations,  and 
a Process  ship  watchstations . 
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The  setup  routine  first  obtains  the  LEVEL  record,  CALC  on  the 
LEVELKLY*  (SHIPl'D  or  UIC,  and  TASK  1 ' : GLEVEL  or  LEVELID)  . If  it  is 
missing  from  the  database,  an  error  message  is  displayed,  and 
control  returns  to  processing  the  next  transaction  card. 

If  the  LEVEL  record  is  found,  the  LEVEL-ROC  set  is  walked  to  load 
the  in-core  ship  ROC  table.  The  following  steps  occur  until  the 
ned  of  the  LEVEL-ROC  set  is  reached:  the  next  ROC  record  in  the 

LEVEL-ROC  set  is  obtained;  if  the  SOCID  is  numeric  and  less  than 
901,  it  is  entered  in  tae  ship  ROC  table  as  an  'X1  in  the  table 
element  subscripted  by  SOCID;  otherwise , an  error  message  is  dis- 
palyed.  When  the  end  of  the  LEVEL-ROC  set  is  reached,  setup  is 
completed,  and  control  passes  to  process  class  vatchstaticns . 

To  process  class  vatchstations  (WS  records  belonging  to  the 
CLASS-WS  set) , first  the  SHIP  record  is  obtained,  CALCed  on  UIC 
from  the  transaction  card.  If  it  is  not  on  the  database,  an  error 
message  is  displayed,  and  control  passes  back  to  process  the  next 
transaction  card.  Then  the  CLASS  record  is  obtained  as  the  owner 
in  the  CLASS-SHIP  set.  The  CLA.SS  record  also  owns  a.  CLASS-WS  set, 
which  contains  all  records  for  all  watchstatio'ns  common  to  the 
entire  ship  class. 

The  CLASS-WS  set  is  walked,  checking  each  watchstation ' s driving 
WSROC  elements  to  see  if  the  watchstation  is  required  by  the  ship's 
ROC,  and  this  process  continues  until  the  end  of  the  CLASS-WS  set. 
First,  the  next  WS  record  in  the  CL/^SS-WS  set  is  obtained.  If 
there  are  no  WS  records  in  the  CLASS-WS  set,  display  an  error 
message.  For  each  WS  record,  if  its  WS -WSROC  set  is  empty,  continue 
obtaining  the  next  WS  record  until  one  is  found  whose  WS-WSROC  set 
is  not  empty. 

When  the  owner  of  the  WS-WSROC  set  is  found,  begin  walking  the  WS- 
WSROC  set,  continuing  until  the  watchstation  is  determined  to  be 
required  by  the  ship's  ROC,  or  the  end  of  the  WS-WSROC  set  is 
found.  A watchstation  is  required  if  either  a WSROC  with  SOCID  = 
zero  is  found,  or  else  a match  is  found  between  the  SOCID  and  an 
entry  in  the  ship  ROC  table.  If  the  end  of  the  WS-WSROC  set  is 
reached,  then  the  current  watchstation  is  not  required  under  the 
ship's  ROC  for  the  given  tasking  level  (LEVEL  record).  Control 
passes  to  continue  obtaining  the  next  WS  in  the  CLASS-WS  set. 

But  if  the  watchstation  is  required,  one  or  more  watchstation 
records  are  generated  from  the  WS  records  for  the  given  watch- 
station . 


r 


i 


Once  a 
first  WS 
dupl  icat  o 
s La  Lemon  t 
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lati  on  in  do  Co  emitted  to  l.»o  requirt -cl , obtain  tho 
rd  with  the  curi  ■ nt  WS  I D CALC  key.  This  allows  all 
KS  records  to  be  obtained  with  the  OHTAJi!  DUPLICATE 
later  in  tho  processing.  Next,  tabulate  tlic  ship 


conditions  represented  by 
r.  iximum  of  seven  on  any  KC 
WS  records.  This  is  done  fen. 
CONDITION  field  is  equal  to  sp 
lic-on  processed  from  a single  W 


;>  to  a 


the  duplicate  V.’S  records, 
ord,  or  a total  of  eight  acre:"  nl 
each  WS  record  until  either  the 
cos,  or  the  seventh  CONDITION  has 
record.  Then  tho  next  du: .! i cate 


WS  record  is  obtain:  ■:?,  and  processed  similarly.  In  each  crane, 
the  CONDITION  is  ent  red  into  the  condition  table.  If  NOWATCH- 
ST ANDERS  on  the  V.’S  record  is  numeric,  it  is  entered  in  the  con- 
dition table;  otherwise,  1 is  entered  as  the  default  NOWA'i’CHSTAN 


jbHS . 


Again,  obtain  the  first  duplicate  WS  record,  by  CALC.  Nov/,  load 
the  WATCHSTATION  record  by  moving  data  from  WS  records  to  the  cor- 
responding WATCH STATION  record  data  elements,  filling  up  to  eight 
conditions  on  the  WATCHSTATION  record.  If  NOWATCIISTANDL’RS  is 
greater  than  1 for  one  or  more  conditions,  additional  WATCHSTATION 
records  will  be  produced  for  those  conditions,  decrementing  the 
number  of  additional  v/atchstanders  on  the  condition  table  by  1 
each  time  a new  one  is  written. 


As  each  WATCHSTATION  record  is  fully  loaded,  move  it  to  a hold  area. 


and  write  it  to  the  WATCHSTATION  file,  DAXMSSWS.  Then  move  from 
the  hold  area  to  the  new  buffer  for  use  in  writing  the  additional 
WATCHSTATION  records  due  to  more  than  one  v/atchstander  under  one 
or  more  conditions.  When  all  WATCHSTATION  records  are  written  for 
the  given  V7SKEY,  return  co/itrol  to  process  the  next  WS  record  in 
the  CLASS-WS  set. 


Finally,  when  the  CLASS-WS  set  end  is  reached,  process  the  SHIR- 
KS set.  Obtain  the  SHI?  record,  walk  to  SHIP-WS  set,  and  process 
exactly  the  same  as  for  the  CLASS-WS  set.  At  the  end  of  the  SHIP- 
WS  set,  all  v/atchstations  for  the  ship/tasking  level  have  been 
processed.  Enter  the  ship/tasking  level  in  a table  of  run  sta- 
tistics to  prevent  the  run  from  being  duplicated  by  a subsequent 
I.OAD  or  PRODUCE  command.  Then  return  control  to  process  tho  next 
transaction  card. 
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MODULE  NMWF02 
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Module  Description . The  VJatchstation  Conversion  Module 
converts  the  physical  sequential  Watchstation  File  to  the  Indexed 
Sequential  Access  Method,  ISJ“  for  input  to  DIP.  The  program 
was  written  under  Contract  F uber  N-00014-7G-C-0473,  effective 
24  November  1975. 


Modulo  Functions.  The  following  functions  are  performed  by 
NMWF02 : 


For  a qiven  ship  and  tasking  level: 

(1)  Read  each  Watchstation  record,  one  at  a time. 

(2)  Assign  a 4-digit  sequence  number  to  each  record, 
beginning  with  '0001'  and  incrementing  by  1. 

(3)  Write  each  Watchstation  record  as  an  ISAM  record 
whose  key  is  UIC,  Tasking  level,  and  sequence 
number. 


The  input  to  NMWF02  is  the  Watchstation  File, 
DAXMSSWS , created  in  program  NMWF01. 


• . 0utPut  from  NMWF02  is  the  VJatchstation  List  as  an 
Index  Sequential  (ISAM)  file. 


Characteristics . 

Input  - the  VJatchstation  File. 

a.  Identification. 

(1)  The  DDNAME  is  DAXMSSWS. 

(2)  The  DSNAME  is  WEUIDAX.MSS . SHIPROC . N . WS . 

(3)  The  record  name  is  IM-WATCHSTATI.ON . 

b.  The  Watchstation  File  is  output  from  NMWF01  to  be  the 
primary  source  for  WATCH  data  in  the  NMRS  Database, 
and  input  to  NMWF02  for  reformatting  as  an  ISAM  file 
for  easier  retrieval  by  DIP. 
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c.  Tho  VJatchst-.it-. ion  File  contains,  for  each  specified 
ship  and  tasking  level,  a complete  list  of  all  watch- 
stations  required  to  be  manned  at  any  ship  condition 
under  the  applicable  Required  Operational  Capabilities 
Statement  (ROC) . Besides  identifying  the  ship,  task- 
ing level,  and  watchstation , the  record  contains  in- 
formation on  the  class,  rating,  rate,  NEC,  organizational 
component,  etc.  for  each  ship  condition  at  which  the 
watchstation  is  manned. 

d.  All  of  the  watchstation  data  is  static. 

e.  The  Watchstation  File  is  a disk  file  that  requires 
one  IBM-3330  disk  track  per  52  Watchstation  records. 


Output  - the  ISAM  VJatchstation  File. 

a.  Identification. 

(1)  The  DDNAME  is  DAXMSSDI. 

(2)  The  DSNAME  is  WEUIDAX . MSS . SHIPROC . N . DI . 

(3)  The  record  name  is  OM-WATCHSTATION. 

b.  The  ISAM  Watchstation  file  is  output  to  be  the  primary 
source  of  WATCH  data  in  the  NMRS  database. 

c.  The  file  contents  are  identical  to  those  for  DAXMSSWS, 
above. 

d.  All  of  the  watchstation  data  is  static. 


e.  The  ISAM  Watchstation  File  is  an  Indexed  Sequential 
(ISAM)  disk  file  that  requries  space  in  cylinders. 
One  track  per  cylinder  is  designated  for  the  system 
index  and  overflow  area.  The  remaining  18  tracks 
per  cylinder  each  will  hold  up  to  44  watchstation 
records . 


Data  Environment. 


Job  Statistics.  A count  of  records  written,  and  a com- 
putation of  iBM-3330  disk  drive  tracks  and  cylinders  needed  to 
hold  the  ISAM  watchstation  file  is  presented  for  use  in  tracking 
the  utilization  of  disk  storage,  and  for  modifying  the  JCL  ac- 
cordingly . 
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Logical  Variables.  A logical  variable  is  used  to  signal 
the  end  of  the  input  watchstation  file,  and  to  trigger  program 
termination  procedures. 


ISAM  Key.  The  ISAM  key  for  the  output  Watchstation  file 
is  built  here,  from  the  UIC  and  LEVEL  ID  of  the  input  Watchstat.  i on 
File  and  a 4-dig.it  sequence  number. 


Program  Logic.  The  Watchstation  to  ISAM  program,  NMWF02 , 
reads  the  Watchstation  file  produced  by  NMWF01  after  is  has  been 
sorted  as  follows: 

a.  UIC  (ascending) , 

b.  LEVELID  (ascending) , and 

c.  WSID  (ascending) . 

First,  it  opens  the  input  Watchstation  File  and  the  output  ISAM 
file.  Then  it  processes  watchstation  records  until  end-of-file 
is  reached  on  input.  Finally,  it  computes  certain  job  statistics, 
displays  them,  closes  the  files,  and  terminates. 

The  processing  of  watchstation  records  consists  in  reading  them 
from  the  Watchstation  File,  building  an  ISAM  key,  and  writing 
them  to  the  ISAM  file.  The  ISAM  file  key  consists  of  the  UIC 
and  LEVELID  from  input,  plus  a sequence  number.  The  sequence 
number  is  reset  to  '0001'  whenever  either  UIC  or  LEVELID  changes 
on  input,  and  is  incremented  by  1 thereafter.  Records  are 
counted  as  they  are  written. 

The  job  statistics  consist  of  records  written  (as  counted  above) 
and  the  IBM-3330  tracks  and  cylinders  needed  to  store  the  data. 
There  are  up  to  44  records  per  track,  and  18  data  tracks  per 
cylinder  (as  the  nineteenth  track  is  reserved  for  the  index  and 
the  overflow  area) . These  statistics  are  computed  and  displayed, 
after  which  the  files  are  closed  and  the  run  terminated. 
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Data  Paso  Dove]  opim-nt  Outline 

1.  Conceptual  Dor. ion 

a.  Identify  major  data  entities 

(1)  Define  each  data  entity 

(2)  Identify  source 

(3)  Characterize  usage 

b.  Identify  inter-relationships  of  data  entities 

(1)  Define  each  relationship 

(2)  Identify  the  data  redundancies 

c.  Design  data  structure 

(1)  Constructing  pro-forma  data  structure 

(2)  Test  for  logical  completeness 

(3)  Document  data  structure 

2 . Detta  Rase  Design 

a.  Identify  record  types 

(1)  Group  data  elements  by  data  entities 

(2)  Define  each  record  type 

(3)  Characterize  usage: 

(a)  Subsystems  to  access  this  record 

(b)  Unique  identifier 

(c)  Secondary  key 

(d)  Volume  estimate 

b.  Identify  inter-relationships  of  records 

(1)  Identify  set-types 

(a)  Define  owner 

(b)  Define  member (s) 

(2)  Define  each  set 

(a)  Description 

(b)  Purpose 

c.  Design  data  structure 

(1)  Combine  records/sets  into  a data  structure 

(2)  Identify  primary  access  paths 

(3)  Identify  major  subsystem  usage  of  the  data 
structure  (SCHEMA) 

(4)  Design  data  structure  (Sub-SCIIEMA)  for  major- 
subsystems 
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d.  Formalize  data  base  design 


(1)  Document  the  data  structure  (SCHEMA) 

(2)  Document  the  data  structure  (Sub-SCHKM/O 


CONCEPTUAL  DESIGN 


This  section  of  the  Data  Base  Development  specification  is  written 
to  provide  the  information  necessary  to  define  the  major  data 
entities.  It  identifies  the  source  of  each  data  entity  within  the 
structure.  In  addition,  it  will  provide  a variety  of  background 
information  and  discussion  relative  to  the  derivation  of  the  data 
structure  diagram  depicted  in  Figure  H-2 . 

Identif ica tion  of  Major  Da t a Entit i qs 

This  paragraph  includes  a definition  of  each  data  entity  and  identi- 
fies the  source  of  each  data  entity. 

A.  CLASS 


The  Ship  Class  record  identifies  a class  of  ships  with  reference  to 
the- prototype  ship  of  the  class.  The  class  is  identified  by  a three 
digit  number,  CL.ASSID,  which  was  arbitrarily  assigned.  It  contains 
pointers  to  ship  and  watchstation  records. 

Data  Source  - The  original  dictionary  of  approximately  110  ship 
classes  was  compiled  by  the  Ship  ROC/Natchstation  team  in  consvlt- 
ation  with  NAVMMACLANT  personnel.  Additional  ship  classes  are  to 
be  assigned  CLASSID's  in-house  at  NAVIiMACL/vNT  as  needed. 

B.  CONDTITLE 

The  Condition  Title  record  relates  the  two  character  ship  CONDITION 
data  element  (e.g. , 1)  to  the  Condition  Title  (e.g.,  CONDITIO;.  I). 

Data  Source  - The  original  Condition  Title  dictionary  contains  11 
ship  conditions  and  their  titles,  and  was  compiled  by  Ship  ROC/ 
Watchstation  team  in  consultation  with  NAVMMACLANT  personnel.  Ad- 
ditional condition  titles  are  to  be  assigned  CONDITIONS  in-house 
at  NAVMMACLANT  as  needed. 

C.  LEVEL 

The  level  record  aggregates  the  elements  of  a specific  ship's 
Required  Operational  Capabilities'  Statement  (ROC).  A ship  may 
have  an  assigned  ROC,  and  many  hypothetical  ROCs  under  consideration 
for  their  manpower  impact.  Each  of  these  ROCs  is  given  a unique 
LEVEL  record,  identified  by  its  LEVELID  for  a given  ship,  to  identify 
the  ROC  and  group  the  ROC  elements  together.  It  is  important  to 
note  that  the  ROC  records  attached  to  a LEVEL  record  take  on  a 
classification  of  CONFIDENTIAL  in  that  an  actual  ship's  ROC  is 
confidential. 
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Data  Source  - The  level  record  j s created  by  an  analyst 
when' tv.  r he  wants  to  cro-i to  a new  (actual  or  hypothot  ioa.l)  ROC 
for  a ship.  The  LEVEL  record  must  bo  created  before  any  ROC 
records  (ROC  elements  of  the  tasking  level)  are  entered  to  the 
sys  tem . 

D.  ROC 

The  ROC  record  identifies  a single  ship's  operational  or  subo;."  ra- 
tional capabilities  of  a ship’s  Required  Operational  Capabilities 
Statement (ROC) . The  combination  of  all  ROC  records  within  a task- 
ing level  constitutes  a ship's  ROC.  The  ROC  clement  is  encoded  as 
a 4-diyit  number  which  can  be  decoded  by  reference  to  the  ROC  title 
record.  It  is  important  to  note  that  the  ROC  records  are  classified 
CONFIDENTIAL  when  they  arc  associated  with  a tasking  level  or  ship. 

Data  Source  - ROC  records  are  entered  as  needed  by  the  analyst 
within  a tasking  level  to  completely  specify  a (real  or  hypothetical) 
ship's  ROC. 

E.  . ROCTITLE 

The  ROC  Title  record  relates  the  4-digit  code  for  a single  ship's 
operational  or  suboperational  capability  (ROC  element)  to  the  ac- 
tual Navy  8-character  code  for  a ROC  element.  The  Navy  code  is 
of  the  form  MMM  ii.jj,  where  MMM  is  the  mission  area  (MOBility, 
Command  And  Control,  etc.),  ii  is  the  operational  capability  num- 
ber, and~jj  identifies  the  suboperational  capability. 

Data  Source  - The  ROC  Title  dictionary  contains  all  ^rational 
and  suboperational  capabilities  identified  in  OPNAVINST  3501. D, 
identified  by  a 4-d.igit  code  and  optionally  by  the  8-character 
official  Navy  code.  A 4-digit  code  was  arbitrarily  assigned  to 
each  of  the  official  codes  by  the  Ship  ROC/Watchstation  team  to 
simplify  data  gathering,  reduce  the  keypunching,  disk  access,  and. 
disk  storage  costs  for  ROC  elements  by  502,  and  provide  a poss.il  le 
technique  for  encoding  ship  ROCs  (by  not  identifying  the  8-character 
official  Navy  code  for  them  on  this  record  type)  so  as  to  r act  the 
security  requirements  on  a non-secure  computer  facility.  Addi- 
tional ROC  Titles  arc  to  be  assigned  4-digit  codes  in-house  at 
N A VMM  A C I .AN  T . 

F.  SHIP 

The  Ship  record  identifies  a ship  by  its  hull  number,  UIC,  and 
name,  and  points  to  the  ship  class  of  which  it  is  a member. 

Data  Source  - The  original  dictionary  of  approximately  500  ships 
was  compiled  by  the  Ship  ROC/Watchstation  team  in  consultation 
with  NAVKMACLANT  personnel.  Updates  to  the  ship  dictionary  are 
to  be  made  in-house  at  NAVMMACLANT  as  needed. 
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The  Watchstation  record  identifies  the  Watchstation  by  its  10- 
character  ID  number,  and  by  the  ship  class  or  individual  ship 
with  which  it  is  associated.  It  identifies  the  wutchstandor  by 
RATE,  RATING,  and  NEC  (if  enlisted)  or  Officer  Designator,  Fay 
Grade,  and  NO BC  (if  an  officer).  Further,  it  specifies  the  ship 
conditions  under  which  the  given  watchs tender  mans  the  watch- 
station,  tlie  organisational  component  from  which  he  comes,  and 
whether  or  not  the  watchstation  can  be  manned  around  the  clock 
by  two  people  rather  than  three  (the  SURGE  Condition)  . 

Data  Source  - The  Ship  PDC/Watchstation  team  has  coded  all 
watchstation  data  for  68  ships  as  of  23  April  1976.  The  data  was 
derived  from  approved  S'- ID  II  documents  where  available,  and  the 
best  available  data  otherwise,  in  consultation  with  NAVMi-IACLANT 
personnel.  Watchstation  data  for  the  remaining  ships  is  to  be 
gathered,  coded,  and  entered  to  the  data  base  using  NAVI4MACLANT 
in-house  or  contractor  personnel  as  directed. 

H . VIS  ROC 

The  Vlatchstation/ROC  record  identifies  an  operational  or  sub- 
operational  capability  which,  to  be  properly  performed,  requires 
the  manning  of  the  specified  watchstation.  Each  watchstation 
must  have  one  or  more  VISROCs  associated  with  it  in  order  for  it 
to  be  included  as  a watchstation  requiring  manning  under  one  or 
more  ship  conditions.  A special  4-digit  code  is  used  to  specify 
the  ROC  element  (see  ROCTITLE) , and  the  code  '0000'  indicates 
a watchstation  which  is  always  required  under  the  ship  conditions 
specified  in  the  watchstation  record,  under  any  possible  (real  or 
hypothetical)  ship  ROC.  It  is  important  to  note  that  the  VJSROC 
records  may  me  classified  CONFIDENTIAL  in  that  they  identify  ele- 
ments of  a ship's  ROC. 

Data  Source  - The  Ship  ROC/Watchstation  team  gathered  this  data 
in  the  form  of  arrays  showing  each  ROC  element,  and  then  identify- 
ing all  watchstations  requiring  manning  in  order  to  satisfy  the 
requirements  of  the  ROC  element.  See  Figure  H-l. 

This  process  involved  assigning  ROC  ID  numbers  to  the  columns  of 
a large  matrix,  Watchstation  IDs  to  the  rows,  and  then  going  down 
each  column  in  turn  to  identify  the  watchstations  required  for  the 
ROC  element.  Once  the  matrix  is  completed,  the  data  is  coded  by 
WATCHSTATION,  i.e.,  across  the  rows,  rather  than  by  column.  Any 
watchstation  (row)  with  more  than  40  ROC  elements  driving  it  is 
coded  as  ROC  element  0000,  in  that  it  will  virtually  always  bo  a 
required  watchstation. 


Since  WSROC  transaction  cards  identify  a ship  and 
elements  (albeit  encoded),  they  may  be  classified 
WSROC  data  is  to  be  gathered,  coded,  and  entered 


a group  of  ROC 
CONFIDENTIAL, 
to  the  data  base 
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only  as  directed  by  lU\VlfAACLA<Yi  upon  resolution  ol  the  seeuri.1;, 
question,  by  in-house  or  contractor  personnel  possessing  the  re- 
quired security  clearance,  as  directed  by  N/iVMMAChANT. 


Watchstations  ROC  EL-iMEIflS 


0000  0001 

0002  0003 

1 1 1 

’ 0900 

WS1 
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X 

WS300 
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Figure  H-l  . 

Watchstations 

Required  by 

ROC 

Elements 

1 

I.  wstitli: 

The  Watchstation  Title  record  identifies  the  nomenclature  associated 
with  a 10-digit  Watchstation  ID  number. 

Data  Source  - The  original  dictionary  of  approximately  6000  watch- 
station  t j ties  was  compiled  by  the  Ship  ROC/Watchstation  team  from 
approved  SMD  II  documents,  and  other  sources,  in  consultation  with 
NAVMMAC1.ANT  personnel.  Updates  and  additions  of  watchstation 
titles  and  the  assignment  of  WSID  numbers  is  to  be  done  in-house  at 
N A VMMACLA NT  as  needed. 
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This  paragraph  defines  the  data  entity  relationships  and,  in  addi- 
tion, contains  special  notes  relative  to  the  processing  of  the  sys- 
tem plus  any  additional  notes  about  the  relationships. 

A.  CLASS 

1.  Tiie  ship  CLASS  record  is  a header  record  which  groups  ships 
together.  Every  ship  class  has  at  least  one  ship,  and  each  ship  is 
a member  of  one  and  only  one  ship  class.  The  set  CLASS-SHIP  con- 
tains ail  ships  in  the  class. 

2.  The  ship  CLASS  record  is  also  a header  for  watchs tations 
common  to  all  ships  of  the  class.  For  a watchstation  record  to  be- 
long to  the  CLASS -V.'S  set,  both  the  watchstation  description 
(Watchs tut  ion  ID  number  and  title,  and  number  of  watchs Landers)  and 
the  watchstander  description  (Rating,  Rate,  NEC,  Org  Code)  must  be 
identical  for  all  ships  of  the  class.  Further,  the  same  set  of  ROC 
elements  must  be  related  to  the  watchstation  in  terms  of  requiring 
its  manning.  The  CLASS-WS  set  contains  all  such  watchstations . 

B.  LEVEL 

1.  The  LEVEL  record  serves  as  an  identifier  of  a tasking  level 
for  a ship  and  the  header  for  the  ship's  Required  Operational 
Capabilities  Statement  (ROC)  at  that  tasking  level.  The  LEVEL-ROC 
set  contains  all  ROC  elements  in  the  tasking  level  for  the  set. 

2.  The  SHIP-LEVEL  set  contains  all  tasking  levels  for  a given 
ship.  The  tasking  level,  in  turn,  contains  the  ship's  Required 
Operational  Capabilities  Statement  (ROC). 

C.  ROC 

1.  See  B.l  for  a description  of  the  LEVEL-ROC  set. 

2.  The  ROC  record  is  also  a member  of  the  ROCTITLE-ROC  set, 
which  links  together  tasking  levels  (and  therefore  ships  and 
classes)  which  contain  a given  ROC  element.  This  could  be  of 

use  if  a given  ROC  element  were  changed  or  deleted  from  the  system, 
and  it  were  necessary  to  determine  the  areas  of  impact.  Keying 
on  the  SOCID  for  a ROC  title  gives  the  ROCTITLE  header  record. 

Then  the  ROCTITLE-ROC  set  can  be  stepped  through  to  list  the 
tasking  levels  and  ships  affected. 

D.  ROCTITLE 

1.  The  ROCTITLE  record  identifier,  a ROC  element  and  serves 
as  header  for  the  sot  of  like  ROC  elements  in  all  tasking  levels. 
See  C.2  for  a description  of  the  ROCTITLF-RCC  sot. 
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1.  See  A . 1 for  a description  of  the  CLASS-SHIP  set. 

2.  See  H.2  for  a description  of  the  SHIP-LEVEL  set. 

3.  The  ship  record,  in  addition  to  heading  all  the  tasking 

levels  for  a given  ship  (SHIP-LEVEL),  also  heads  all  watchstations 
for  the  ship  which  are  not  common  to  all  ships  of  the  class.  This 
SIll'P-WS  set  contains  only  those  watchstations  for  the  ship  which 
are  not  already  members  of  the  CLASS-W5  set.  In  order  to  see  all 
wal dictations  assigned  for  a ship,  it  is  necessary  to  pass  through 
the  entire  SIIIP-WS  set  for  the  given  ship  then  the  entire  CLASS-WS 
set  for  the  class  containing  the  ship.  The  CLASS-SHIP  set  contains 
pointers  to  the  CLASS  record  from  each  ship  (owner  pointers)  to 
facilitate  this  process.  See  the  CLASS-SHIP  and  CLASS-WS  sets 

(A . 1 and  A. 2,  respectively ) for  further  explanation. 

F.  WS 

< 

1.  See  A . 1 for  a description  of  the  CLASS-WS  set. 

2.  See  E.3  for  a description  of  the  SHIP-WS  set. 

3.  Each  watchstation,  in  order  to  be  manned  at  some  ship  condi- 
tion, must  be  driven  by  one  or  more  required  operational  or  sub- 
operational  capabilities  (ROC  elements)  of  the  ship's  Required 
Operational  Capabilities  Statement  (ROC).  The  WS-WSROC  set  contains 
all  the  ROC  elements  which  are  capable  of  driving  the  watchstation, 
if  they  wore  part  of  the  ship's  ROC  at  the  given  tasking  level.  If 
any  one  of  the  ROC  elements  in  the  WS-WSROC  set  is  also  in  the  LEVEL- 
ROC  set  for  the  ship  and  tasking  level  of  interest,  the  watchstation 
is  required  to  be  manned  as  specified  in  the  WS  record.  Otherwise, 
the  watchstation  is  omitted.  See  the  LEVEL-ROC  set  for  further 
details  (B . 1) . 


This  paragraph  contains  a description  of  the  pro-forma  data  struc- 
ture of  the  Ship  XOC/Watchstation  Module  of  NMR5 , which  is  de- 
picted in  Figure  H-2  , 
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C.  SHIP-WS 

Each  ship  may  contain  one  or  more  watchstations  which  are  not  com- 
mon to  all  ships  of  the  class.  Where  a given  watchstation  occurs 
for  several,  but  not  all,  ships  of  the  class,  the  watchstation 
record  is  repeat'd  as  necessary  for  each  applicable  ship.  A 
watchstation  may  or  may  not  belong  to  a ship;  it  may,  instead,  be 
common  to  all  ships  of  the  class.  In  that  case,  it  belongs  to  the 
CLASS-WS  set,  and  not  to  the  SHIP-WS  set. 

D.  SHIP-LEVEL 

Each  ship  may  possess  one  or  more  tasking  levels,  which  are 
identified  by  ship  and  level  ID.  Each  tasking  level  belongs  to 
one  and  only  one  ship.  Different  ships  may  have  identical  tasking 
levels,  but  their  identification  by  ship  will  differ,  and  all 
information  will  be  separately  stated . 

E . LEVEL- ROC 

Each  tasking  level  may  contain  one  or  more  ROC  elements,  and  each 
P.OC  element  may  appear  in  one  or  more  tasking  levels.  For  simpli- 
city of  processing,  each  tasking  level  has  a separately  stated 
list  of  ROC  elements.  Because  the  ROC  record  is  at  the  minimum 
size  for  IDMS  records,  no  disk  storage  savings  can  be  effected 
through  the  use  of  link  records. 

F.  WS-ROC 

Each  watchstation  may  be  driven  by  one  or  more  ROC  elements,  and 
each  ROC  element  may  drive  one  or  more  watchstations.  Because  the 
WSROC  record  is  at  the  minimum  size  for  IDMS  records,  no  disk 
storage  savings  can  be  effected  through  the  use  of  link  records. 
Therefore,  each  driving  ROC  is  separately  stated  for  each  watch- 
station . 


IDMS  Data  St  mature 

This  paragraph  briefly  describes  the  IDMS  data  structure  of  the 
Ship  ROC/Watchstation  Module  of  NMRS,  as  depicted  in  Figure  H-3. 
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DATA  BASH  DESIGN 


Schemas 

Currently,  only  one  schema  exists  for  the  Ship  ROC/Watchstation 
Hod  u 1 e . 

A . GHPROC.ES 

Other  test  versions  of  the  schema  care  expected  when  the  Ship  ROC/ 
Watchstation  Module  database  is  incorporated  within  the  NMRS  data- 
base . 


DHCIjS 

Currently,  only  one  Device  Media  Control  language  (DMCL)  exists 
for  the  Ship  ROC/Watchstation  Module: 

. A*  bmubbate 

As  the  purpose  of  the  DMCL  is  to  fine-tune  system  performance  in 
production  mode,  additional  test  versions  of  the  DMCL  are  expected 
when  the  Ship  ROC/Watchstation  Module  goes  into  production  on  a 
secure  computer  facility. 


Subschemas 


Currently,  only  one  Subschema  exists  for  the  Ship  ROC/Watchstation 
Module : 


A . nUGTESTB 


As  this  is  sufficient  for  all  processing  currently  being  done  as 
well  as  all  identified  modifications,  no  additional  subschema  are 
envisioned. 


Database  Files 


Two  database  files  currently  exist  for  the  Ship  ROC/Watchstation 
Module : 

A.  SROCWSMN 

D.  SROCWSRC 


11-12 


Thin  data  structure  is  divided  into  four  realms: 


(1)  WSDICT , 

(2)  SIIIPCLASS, 

(3)  WSCONDROC , and 

(4)  ROCLEVEL 

The  WSDICT  realm  contains  dictionary-type  information  or  watch- 
station  titles  and  ship  condition  titles.  The  ship  class  realm 
contains  ship  and  class  dictionary  information,  and  their  inter- 
relationships. The  WSCOMDROC  realm  contains  v/atchs tat  ions  by  ship 
conditions,  and  the  HOC  elements  which  drive  them.  The  ROC REVEL 
realm  contains  tasking  levels  and  the  ROC  elements  comprising  them, 
as  well  as  a dictionary  of  ROC  element  titles. 


As  the  database  files  are  the  physical  basis  for  the  logical  data- 
base, they  are  highly  dependent  on  the  nature  of  the  host  computer 
facility  and  its  restrictions.  Changes  to  the  sizes  of  those  files 
are  certain,  as  they  are  merely  small  test  data  sets  at  present. 

The  quantity  of  files,  and  their  names,  may  well  change  upon  inte- 
gration into  the  NMRS  database,  or  upon  transfer  to  another  computer 
facility.  These  changes  are  completely  transparent  to  the  applica- 
tion programmer  and  system  user;  they  arc  solely  the  responsibility 
of  the  Database  Administrator  and  his  staff. 


Realms 

Four  Realms  currently  exist  in  the  Ship  ROC/Watchstation  Module: 

A.  WSDICT 
13 . SHIPCLASS 
C • WSCONDROC 
D . ROC LEVEL 

These  realms  serve  to  group  data  functionally,  aid  in  system  test- 
ing, and  to  enhance  system  performance.  No  changes  to  Realms  arc 
envisioned,  although  such  changes  would  be  transparent  to  the 
existing  application  programs  find  the  system  users. 

Record  Types 

Nine  record  types  currently  exist  in  the  Ship  ROC/Watchstation 
Module : 

A.  CLASS 


B.  CONDTITLE 
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c. 

LEVEL 

D. 

ROC 

F,. 

ROCTTTLE 

F. 

SHIP 

G. 

KS 

H. 

VJSROC 

I. 

WSTITLE 

Sots; 


Seven  sets  currently  exist  in  the  Ship  ROC/Watchstation  Module: 

A . CLASS- SHIP 

B . CLASS -'IS 

C . LEVrh-ROC 

D.  ROCTITLE-ROC 

E . SHIP-LEVEL 

F.  SHIP-WS 

G.  WS-WSRO C 


Miscellaneous . 


a.  Special  programs  to  list  any  record  type,  or  set  in  the 
database.  (Only  if  comnands/repcu: ts  to  do  so  arc-  not 
part  of  the  deliverables) . 

A number  of  I CMS /CULP HIT  report  programs  are  included 

A.  Condition  Title  Report 

B.  P.OC  Title  Report 

C.  ROC  Report 

D.  Watchstntion  Titles  Report 

E.  KaLchstation/ROC  Relationship  Report 

These  reports  arc  further  documented  in  Culprit  Reports  of 
the  Ship  ROC/Watchstation  Database. 


H- 14 


b.  Loca 
code 

All 

SHJPROC 
j \;  \ i ntcn  i. 
volume  c 
VJatchsta 


Lion  (Dataset  Name  and  Volume)  of  all  riles  (source 
, object  cole,  etc.). 


files  are  cjiven  names  with  the  pre/.i.  : \vi2UlDAi  . > VS . 
to  clearly  identify  the  group  responsible  for  their 
'■•co,  Fo  13  owing  is  a list  of  a "'..'I  dai  *?.» 

crial  numbers,  currently  main .. aimed  by  tlic  Sh.ip  i .-.-i:/ 
tion  Team  at  Nil!  (prefix  omitted  here)  : 


A.  CLU CARDS 

B.  DATADICT 

C.  DAT ALIB 

D.  IDMSLl'B 

E.  L0.ADL1B 

F . ROC 

G.  SKCELIB. COBOL 

II . SRCELIB  . FORTRAN 

I . UTCNTROL 

J . V?S 

K.  WSKA1N 

' L.  N. DATADICT 

M.  N . IDAS LIB 

N.  N . LOADLIB 

O . N . ROC 

P.  N.SRCELIR. COBOL 

Q.  N . If  DMA  IN 


RILE  If. 
Vll  LEJ 6 
PDSOO 4 
RILE. If 
PDSOO/ 
RILE If 
PDS004 
PDSOO 4 
RILE1G 
RILE 16 
FILE If 
FILE 1C 
RILE1G 
PDSOO 4 
RILE IV 
PDSOO/. 
J’XLEl  / 
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